Challenges when duplicating an HTML page

Wappler General Bugs
#1

Not sure if this should be a bug report or feature request, but I’m leaning towards a bug since we have the ability to duplicate a file.

I use Wappler mainly in the code editor view. I also duplicate pages to speed up development (e.g., Create a Contact page and duplicate it for the Company page).
image

Then in the code view of the duplicated page, I will find/replace all references to switch from one page to another (e.g. Replace Contact with Company).

The issue with this approach is that the dmxAppConnect config.js file is not updated, which leads to UI issues in Wappler when trying to use components like the Formatter on the new page, as I reported in Add New Formetter button not working.

This means I have to also make manual updates to the config.js file to copy all of the items to the new page’s section and rename them.

image
image1126×246 14.8 KB

Add New Formatter button not working
#2

I’m not sure if it is a bug or an FR either but I find using ‘Save As’ instead of duplicating works much better. At least for PHP pages.

#3

Indeed simply duplicating a file won’t rename the App ID in it used for App Connect meta data storage and this can give conflicts.

Not sure yet how this can be improved, we have no idea that the file you are duplicating even have App Connect in it.

Maybe this can be done from the pages Manager only.

#4
#5

Is there a way for Wappler to check, or just update, the config.js file when I perform a save on the file? Currently, it seems the config file is only updated when you perform certain actions in the UI (e.g. creating a page flow and adding actions to it, or adding a component like query manager and adding variables to it).

I ran into this here as well when I was in an existing page and copying data view elements via code view. Data View filter not showing proper values in Expression Builder

#6

I realise I’m probably missing the point, but, if I understand correctly, you would like a new App ID to be created when you duplicate a page, and the corresponding entries to be created in config.js. I would prefer it as it is - and have the same App ID for every page, at least in most cases, and have access to the settings in config.js available to every page.

If you usually duplicate a page instead of creating a new one (as I do), wouldn’t every page have a different App ID if your request were implemented - which would probably require much duplication of the settings in config.js. Or do you not mean this and just want config.js updated (but then I don’t see why it would need updating)?

#7

Yes.

I believe every page is supposed to have a different app id.

Creating a page from scratch doesn’t make sense when I’ve already created every part of the UI and only need to show different data.

Like changing this

image
image1912×745 64.7 KB

To this

image
image1906×672 50 KB

#8

Why?

I realise part of my reply was rather careless and ambiguous. When I wrote ‘as do I’, I was referring to the whole of that sentence - in other words, I do exactly as you do: I almost never create a page from scratch; I always duplicate existing pages.

I would have thought that it’s an advantage for every page to have the same App ID, so metadata for the UI is available to all pages. If you have different IDs for each page, surely there would be a lot of duplication within config.js and additional maintenance.

#9

The meta data is changing as well. Plus there may be divergences in the pages in the future, so having them as separate sections in config.js seems appropriate.

As an example, on my Contacts page, I have a ContactsFlow that has a contactId. Both of those would change to company (i.e. CompanyFlow and companyId).

image

I could try to rewrite them to use more generalized names and parameters (e.g. PageFlow and recordId), but at this point that would require too much rework. :slight_smile:

#10

I think there can be advantages to either approach: either every page having a unique App ID or every page having the same ID (or perhaps a combination of the two). Having said that, I don’t think I’ve ever found a need to use different IDs.

I would have thought in most cases you would want metadata for the UI to be available to all or at least most pages - eg cookies or datastores. If duplicating a page meant a unique ID was assigned each time, should such data be duplicated within the context of the new page, or should it be only added manually each time? Should renaming of variables etc. apply to the current page or to corresponding definitions in other contexts (ie within config.js)?

I would have thought what you’re suggesting makes things more complicated. I have sometimes thought it more of a bug that each page is created with a new App ID. One solution might be to add a new option: to create new pages with a site App ID or a page-specific one.