Remove White screen in Oracle MAF applications - jdeveloper

I am using springboard in my application and have multiple task flows. So, whenever i switch from one feature to another feature a white screen flicker screen comes on task flow change among feature.This screen is also coming in MAF examples as well given by oracle.I want to remove that white screen coming for a short while on first time load of task flow
feature.Please reply me that how can i achieve it.
jdeveloper version : 12.1.3
maf : 2.2.2

Anand, we (I'm an Oracle employee) recently received a similar question internal to Oracle from Oracle Support on behalf of a customer. Presumably that customer was you and you already have an answer. Let us know otherwise.
Post edit in response to Anand's follow up answer.
No worries, here’s the details of the issue you’re seeing. I’ll attempt to describe why it's happening, and how you can potentially change your app to reduce this problem.  While the description is long, it isn't actually that difficult to make these changes, it just takes a lot of words to explain!
In addition, I recommend you DO NOT make these changes permanent without a FULL ROUND OF REGRESSION TESTING.  These changes will fundamentally change how your app is composed, so I can't guarantee it won’t break some of your logic.  In order for you to make these changes and have confidence that nothing breaks, you also need to undertake a FULL ROUND OF REGRESSION TESTING before you make the changes, then compare it to the results of the post-change regression test, so you can differentiate from existing issues and new issues introduced by these changes.
So let's take a step back and describe why the issue occurs.
Firstly, as you’ve noted the issues happens the first time the application opens, and the first time you open a feature with an associated task flow. If you have a springboard with many features, as you skip between the features and they each start for the first time you will see this white flash for each (only the first time, not on each subsequent reopening). It also slightly delays the navigation to that task flow depending on the speed of your device.
Second, this issue will be much more noticeable on slower devices or in the Android emulator without HAXM as it is associated with a performance bottleneck. As MAF runs faster on iOS it’s hard to see this problem at all, and on modern Android devices in turn it's hard to see as it is too quick.  As example on my older 1.5Ghz 2nd-gen 2013 Nexus 7 tablet I can see the white flash, most modern Android phones have a 2Ghz+ processor and I’ve not really noticed this problem any more. In turn as a developer you will see the flash more often as you will be continuously killing & redeploying the app which results in a restart of the app and the flash appearing the first time the app & each feature are opened/restarted again. (real users will see this much less often as they tend to stick to a couple features in most apps, and leave the app running in the background so the features are already initialized)
So why does the flash occur, and the associated delay in navigation?
When a feature is first called, MAF initializes a number of things in the background, including a classloader per feature.  That initialization for whatever reason is costly in terms of performance, and during the processing can result in the UI being cleared which results in the white screen. I coin this effect the “white screen flash”.
Once a feature has been initialized, the speed underwhich it renders is much faster and you're unlikely to see the flash as everything is now safely initialized. In other words the problem is only noticeable for the first time a feature is rendered. If you re-open the feature, it will be too quick to see as the classloader is already loaded.
As we now know what is causing the problem, what can we do to avoid this assuming Oracle won’t fix or optimize the issue? (and in fairness the MAF development team did optimize MAF heavily in the 2.2 release).
Ultimately the solution is to reduce the number of features in your application, and ultimately (if possible) reduce this to just 1 feature so when the app starts you get the white flash once, but not again. But that begs the question, when MAF pushes you towards using features invoked by the springboard, how do you do this? Can we really reduce all the features?
If you think about your MAF application, you will typically have 1 feature for the springboard, then lots of other features for various useful parts of your app. Let’s call that the “springboard” feature (singular), and the “logic” features (plural).
The solution is therefore to:
1) move everything from your existing logic features (but the springboard feature), that is all the AMX pages, and other components such as managed bean in your task flows into 1 new single logic feature. For each of the preexisting logic features now embedded in that single new logic feature, create a wildcard navigation for each so they can be accessed and give each a name. eg. goFirstFeature, goSomeOtherNameFeature etc
2) for the current springboard feature it will stay, but we need to change how it works.
Typically customers create a springboard feature with a listview to navigate to their features (rather than use the autogenerated springboard).  As our goal is to eliminate the logic features and replace them with the new single logic feature, the original springboard won’t work as it’s designed to call the other original individual business features (rather than our new super single logic feature).
Instead what we need to do is hardcode the ListView with ListItems to call each individual (logical) feature in our new single logic feature using the wildcards.  Something like the following:
<amx:commandButton text="Go First Feature" id="cb1" actionListener="#{viewScope.myBean.goFirstFeature}"/>
<amx:commandButton text="Go Second Feature" id="cb2" actionListener="#{viewScope.myBean.goSecondFeature}"/>
This is backed by a bean with the following code:
public class MyBean {
    private void doFeatureNavigation(
      String featureId, String navigationFlowCase) {
        AdfmfContainerUtilities.hideSpringboard();
        AdfmfContainerUtilities.invokeContainerJavaScriptFunction(featureId,
            "adf.mf.api.amx.doNavigation", new Object[] { navigationFlowCase });
    }
    public void goFirstFeature(ActionEvent actionEvent) {
        doFeatureNavigation("package.name.of.new.single.logic.feature", "goFirstFeature");
    }
    public void goSecondFeature (ActionEvent actionEvent) {
        doFeatureNavigation("package.name.of.new.single.logic.feature", "goSecondFeature");
    }
}
Note how the code hides the springboard, then in context of the single business feature navigates to one of the wild card navigation rules you setup earlier in the new single logic feature.
3) if any of your existing logic features have AMX pages with command controls that navigate to any other logic features, you will need to change the code to call the wildcards:
<amx:commandButton id="cb5" action="goFirstRequest"/>
So it feels like a lot of explanation, but it really is 3 steps. Having done this then satisfactorily tested the app, you can start eliminating the redundant original logic features + task flows. Do not delete any AMX pages, pageDefs or beans, just delete the redundant features and task flows.
I’ve made a lot of assumptions along the way here in proposing the solution as I haven’t seen your app. But I hope this will give you a flavor of what the solution is.
And also you really need to think about is this a big problem and should you really undertake the solution. Personally with the latest optimized versions of MAF on Android, and faster Android devices I’ve not seen this problem for some time. Basically the white-flash is so quick that it’s just no longer a noticeable problem. In turn as real mobile users keep the app running in the background, they see this problem once, and won’t see it for sometime again until they kill the app and restart. So you need to think about are you fixing a problem that may not be seen by the majority of your customers.

Related

Record User Interaction for a Tcl Tk Test Automation

I want to do some tests on our tcl tk application regarding the user interaction. As the application has parts similar to a CAD for which every mouse movement is relevant, I would like to do something like record all events of some user interactions. My goal would be to playback these events laterwards and on every program change to discover potential changes. Or even better to assure the GUI behaves always the same and produces always the same data.
I know, that I can generate some enter motion and button events, but this would not be the same like the thousands of events generated by a real user interaction. But it is very important for me to have exactly these thousands of events.
Is there any possibility to achieve this?
It's relatively easy to record events of particular types with bind — you'll find that <ButtonPress>, <ButtonRelease>, <Enter>, <Leave>, <FocusIn>, <FocusOut>, <KeyPress> and <KeyRelease> cover pretty much everything that you are interested in — and then play them back with event generate. (You need to record quite a bit of information about each event in order to regenerate it correctly, but the underlying model is that of X events with similar names.) Assuming you're not wanting to support inter-application cut-and-paste or drag-and-drop for the purposes of recording; those complicate things a lot. You'll likely have a lot of events; recording to an SQLite database might make a lot of sense.
However, you should think carefully about which parts of the application you want to record. Does it matter if the order of two buttons in the outer shell of the application outside the CAD-like area get swapped in order? For most users, provided you're clear about what the buttons do (through clear labels and icons) it isn't very important, but for replaying recorded events it can matter hugely. Instead, for the parts of the application that are simple buttons and edit fields, I'd not record the details of them but would instead just record when the buttons are clicked and the changes to the text content of entries and so on. In effect, it's capturing higher-level events, and that's much easier to replay correctly. It's only when the user is in that main CAD area that you need the full detail.
Also, beware of changes to font sizes and screen sizes/scaling. They can change how things are laid out and may happen because of system-level alterations outside the scope of your application.
We started out the way you describe: record all those thousands of motion events, etc. Including exact timings which are extremely important for a GUI application as well.
It quickly became appearent that those recordings became too hard to maintain. They are also overly brittle in light of UI changes. Another problem where the hardcoded time values. A switch to a more powerful machine (or a cpu under load) would break the execution.
The two biggest improvements we introduced
Event compression: recognize the high-level action the user wanted to perform (like selecting a menu item). The recorded activateItem command would then perform the necessary work (event emulation) on replay.
Synchronization functions: instead of relying on a particular timing commands like waitForObject wait for an object to come into existance and become ready for interaction.
It took several years for this to work fluently, however. Including a central Object Map repository, property and screenshot verifications, high-level test descriptions in BDD and others. Feel free to take a look a the Squish for Tk product that came out of this work.

Delays in updating content controls when more context.sync() are used on WORD for Mac

We update content control for every character typed in the task pane’s input field. So that user can see the live updates on the word document.
Recently we added functionality for locking content controls. And it happens as below:
User input (types a character) in a input field
We search a content control for that input field (involves context.sync)
Unlock the content control (involves context.sync)
Update value in content control (involves context.sync)
Lock back the content control (involves context.sync)
All this works nice in Word for windows without problems.
But is extremely (visibly) slow with Word for Mac (apple machines)
How should I overcome the delays happening on Mac?
As Juan mentioned in the comment, there are some important details that the team would need to investigate. Sample code would be good too.
That being said, just looking at what you describe, I think you can dramatically cut down on the context.sync() statements. Unlocking the content control, updating its value, and locking it should all be possible to do in one sync.
I have a bunch of details about minimizing sync-s in my book, "Building Office Add-ins using Office.js. Quoting one of the sections from it:
As an add-in author, your job is to minimize the number of context.sync()
calls. Each sync is an extra round-trip to the host application; and when
that application is Office Online, the cost of each of those round-trip adds up
quickly.
If you set out to write your add-in with this in principle in mind, you will
find that you need a surprisingly small number of sync calls. In fact, when
writing this chapter, I found that I really needed to rack my brain to come up with a scenario that did need more than two sync calls. The trick for
minimizing sync calls is to arrange the application logic in such a way that
you're initially scraping the document for whatever information you need
(and queuing it all up for loading), and then following up with a bunch
of operations that modify the document (based on the previously-loaded
data). You've seen several examples of this already: one in the intro chapter,
when describing why Office.js is async; and more recently in the "canonical
sample" section at the beginning of this chapter. For the latter, note that the
scenario itself was reasonably complex: reading document data, processing
it to determine which city has experienced the highest growth, and then
creating a formatted table and chart out of that data. However, given the
"time-travel" superpowers of proxy objects, you can still accomplish this task
as one group of read operations, followed by a group of write operations.
Still, there are some scenarios where multiple loads may be required. And in
fact, there may be legitimate scenarios where even doing an extra sync is the
right thing to do – if it saves on loading a bunch of unneeded data. You will
see an example of this later in the chapter.

Are these still valid negatives against using Storyboards in developing iOS 6 applications?

Using storyboards in lieu of the traditional .xib strategy is something I'm still wrestling with as there is some hesitancy about adopting something that does so much under-the-covers without really understanding what it is doing, and what control I'm really losing.
The BNR iOS Programming Book highlights several "cons" to using Storyboards. I've listed them below, and my question is: Are these negatives still valid with iOS 6?
Storyboards are difficult to work with in a team
Storyboards screw up version control
Storyboards disrupt the flow of programming
Storyboards sacrifice flexibility and control for ease of use
Storyboards always create new view controller instances
I'm looking for answers from guys who are actually building, and preferably deployed real iOS applications and have struggled with the "storyboards vs .xib" thing themselves.
Thanks
I don't think iOS 6 fixes any of these situations. More to the point, xcode 4.5 doesn't fix them or even attempt to do so. The issues listed seem to reflect opinions or stylistic preferences, and perhaps some misinformation. These aren't the kind of thing that COULD be fixed in code.
I'm using storyboards for a substantial app and I find them to be a real productivity boon. I encourage you to try them to see if you don't agree.
A couple of comments on the issues list:
I'm not aware of any issues with teams and SBs, but if 2 were true
(which it isn't) that would explain this concern. I think this is a
misconception based on 2.
Not true. I use Git religiously, and commit frequently. No problemo. During commits, SBs are displayed in their source code form (XML). The diffs work perfectly and actually provide some insight into how SBs are implemented. This reduces the feeling of mysterious "under the covers" behaviors, which becomes a non-issue with familiarity.
Disagree. They don't disrupt the flow, they offer a different flow - which is where they get their power. Lots of programmers find value in the separation imposed by the MVC discipline. SBs introduce a separation between UI element placement and the supporting code. It's a natural split, and eliminates a ton of mindless code (which eliminates the opportunity for typos, and "de-clutters" the REAL code that remains).
Partly agree - they definitely improve ease of use. But I don't find any sacrifice at all. Even when using SBs you can always revert to hand coding any objects if you need to. There's no sacrifice of flexibility or control.
Not sure what this means, and why it might be a problem. Of course we create different VCs for different scenes - that's natural. But it's certainly possible to reuse VC classes in SBs. This item might be a misconception about how to set the class for a SB object. It's easy to forget to do this step, and it sometimes baffles beginners. But it's trivial to correct, and setting the class quickly becomes a habit.
For me the real concerns are:
Using SBs demands a lot of screen real estate for development. Using SBs can be frustrating on a small display.
Highly complex UIs with many many scenes should be split into multiple SBs. Multiple SBs are fully supported, but it's easy to fail to do it. (It's like refactoring a method that gets too big. Usually I notice that I need to refractor code AFTER something has already gotten messy.)
The convenience of SBs during layout and the elimination of so much of the boilerplate code that clutters up VC objects is a huge benefit. (Every line of code that I eliminate is a line I can't screw up, and a line that can't obscure the real code that remains.)
In short, I can't imagine going back to life without SBs. Yes, it is a change. But I haven't found any real serious downside. It's especially important to keep in mind that even when using SBs, all the non-SB coding techniques still work. Give SB's a try, and report your own experience. Good luck!
I generally agree with jbbenni. The only "valid" criticism I see in your points was that about "Storyboards always create a new instance." Basically, this meant that though you could wire up a button to push a view controller on the stack, you could not wire up a button to pop back up the stack without extra code. This has been resolved in Xcode 4.5 with "exit segues", which let you indicate that you want to pop back to a previous controller rather than creating a new instance.
The other limitation of storyboards many complained about was that you could not embed child view controllers in the storyboard itself. This has also been addressed in Xcode 4.5.
Storyboards are a significant step forward for iOS development. Complaints like "it makes merging hard" are unfounded; storyboards are no harder to merge than other code; you just have to take the time to actually read the diff instead of glossing over it as "not Obj-C; can't read."
I've used storyboards successfully in a team setting since their introduction. Don't let the uninformed scare you off. They're great.

What makes a JavaFx 1.2 Scene Graph Refresh?

My first question =). I'm writing a video game with a user interface written in JavaFx. The behavior is correct, but I'm having performance problems. I'm trying to figure out how to figure out what is queuing up the refreshes which are slowing down the app.
I've got a relatively complex Scene Graph that represents a hexagonal map. It scales so that you could have 100 or a 1000 hexagons in the map. As the number of hexagons grow the responsiveness of the gui decreases. I've used YourKit (a Java Profiler) to trace these delays to major redraw operations.
I've spent most of the night trying to figure out how to do two things and understand one thing:
1) Cause a CustomNode to print something to the console whenever it is painted. This would help me identify exactly when these paints are being queued.
2) Identify when a CustomNode is put on the repaint queued.
If I answered 1 and 2, I might be able to figure out what it is that is binding all these different nodes together. Is it possible that JavaFX only works through global refreshes (doubtful)?
JavaFX script is a powerful UI language but certain practices will kill performance. Best performance generally boils down to:
keeping the Scene Graph small
keeping use of bind to a minimum (you can look at using triggers instead which are more performant)
This blog post by Jim Weaver expands these points.
I'm not sure as to the specific answers to your questions. If you examine the 1.2.1 docs you might be able to find a point in the Node documentation that you can override and add println statements but I'm not sure it can be done. You could try posting on forums.sun.com
This is a partial post. I expect to expand it after I've done some more work. I wanted to put in what I've done to date so I don't forget.
I realized that I'd need to get my IDE running with a full compliment of the JavaFx 1.2 source. This would allow me to put break points into the core code to figure out what is going on. I decided to do this configuration on Eclipse for remote debugging. I'm developing my FX in Netbeans but am more comfortable with Eclipse so that's what I want to debug in if I can.
To get this info into Eclipse, I first made a project with the Java source that my code uses. I then added external Jars to the project. On my Mac, the Jars I linked to were in /Library/Frameworks/JavaFX.framework/Versions/1.2
Then I went searching for the Source to link to these Jars. Unfortunately, it's not available. I could find some of it in /Library/Frameworks/JavaFX.framework/Versions/1.2/src.zip.
I did some research and found that the only available option left was to install a Java Decompilier. I used this one because it was easy to install into Eclipse 3.4: http colon_ //java dot decompiler _dot free.fr/ (<-- Please forgive the psudo link, I'm limited because I'm new)
This is where I am now. I can navigate into the Core FX classes and believe I'll be able to set break points and begin real analysis. I'll update this post as I progress.
I found a helpful benchmarking tool:
If you run with the JVM arg:
-Djava.util.logging.config.file=/path/to/logging/file/logging.properties
And you've put the following args into the file referenced by that arg:
handlers = java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level = ALL
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
com.sun.scenario.animation.fps.level = ALL
You'll get console output that includes your frame count per second. For FX 1.2 it wasn't working for me, but it appears to be working for 1.2.1 (which was released Sept. 9, 2009.) I don't have a Netbeans that runs 1.2.1 yet.
You may want to read this article.
http://fxexperience.com/2009/09/performance-improving-insertion-times/
Basically, insertions in to the scenegraph are slow and benefits can be seen by batching up inserts

Generating UI from DB - the good, the bad and the ugly?

I've read a statement somewhere that generating UI automatically from DB layout (or business objects, or whatever other business layer) is a bad idea. I can also imagine a few good challenges that one would have to face in order to make something like this.
However I have not seen (nor could find) any examples of people attempting it. Thus I'm wondering - is it really that bad? It's definately not easy, but can it be done with any measure success? What are the major obstacles? It would be great to see some examples of successes and failures.
To clarify - with "generating UI automatically" I mean that the all forms with all their controls are generated completely automatically (at runtime or compile time), based perhaps on some hints in metadata on how the data should be represented. This is in contrast to designing forms by hand (as most people do).
Added: Found this somewhat related question
Added 2: OK, it seems that one way this can get pretty fair results is if enough presentation-related metadata is available. For this approach, how much would be "enough", and would it be any less work than designing the form manually? Does it also provide greater flexibility for future changes?
We had a project which would generate the database tables/stored proc as well as the UI from business classes. It was done in .NET and we used a lot of Custom Attributes on the classes and properties to make it behave how we wanted it to. It worked great though and if you manage to follow your design you can create customizations of your software really easily. We also did have a way of putting in "custom" user controls for some very exceptional cases.
All in all it worked out well for us. Unfortunately it is a sold banking product and there is no available source.
it's ok for something tiny where all you need is a utilitarian method to get the data in.
for anything resembling a real application though, it's a terrible idea. what makes for a good UI is the humanisation factor, the bits you tweak to ensure that this machine reacts well to a person's touch.
you just can't get that when your interface is generated mechanically.... well maybe with something approaching AI. :)
edit - to clarify: UI generated from code/db is fine as a starting point, it's just a rubbish end point.
hey this is not difficult to achieve at all and its not a bad idea at all. it all depends on your project needs. a lot of software products (mind you not projects but products) depend upon this model - so they dont have to rewrite their code / ui logic for different client needs. clients can customize their ui the way they want to using a designer form in the admin system
i have used xml for preserving meta data for this sort of stuff. some of the attributes which i saved for every field were:
friendlyname (label caption)
haspredefinedvalues (yes for drop
down list / multi check box list)
multiselect (if yes then check box
list, if no then drop down list)
datatype
maxlength
required
minvalue
maxvalue
regularexpression
enabled (to show or not to show)
sortkey (order on the web form)
regarding positioning - i did not care much and simply generate table tr td tags 1 below the other - however if you want to implement this as well, you can have 1 more attribute called CssClass where you can define ui specific properties (look and feel, positioning, etc) here
UPDATE: also note a lot of ecommerce products follow this kind of dynamic ui when you want to enter product information - as their clients can be selling everything under the sun from furniture to sex toys ;-) so instead of rewriting their code for every different industry they simply let their clients enter meta data for product attributes via an admin form :-)
i would also recommend you to look at Entity-attribute-value model - it has its own pros and cons but i feel it can be used quite well with your requirements.
In my Opinion there some things you should think about:
Does the customer need a function to customize his UI?
Are there a lot of different attributes or elements?
Is the effort of creating such an "rendering engine" worth it?
Okay, i think that its pretty obvious why you should think about these. It really depends on your project if that kind of model makes sense...
If you want to create some a lot of forms that can be customized at runtime then this model could be pretty uselful. Also, if you need to do a lot of smaller tools and you use this as some kind of "engine" then this effort could be worth it because you can save a lot of time.
With that kind of "rendering engine" you could automatically add error reportings, check the values or add other things that are always build up with the same pattern. But if you have too many of this things, elements or attributes then the performance can go down rapidly.
Another things that becomes interesting in bigger projects is, that changes that have to occur in each form just have to be made in the engine, not in each form. This could save A LOT of time if there is a bug in the finished application.
In our company we use a similar model for an interface generator between cash-software (right now i cant remember the right word for it...) and our application, just that it doesnt create an UI, but an output file for one of the applications.
We use XML to define the structure and how the values need to be converted and so on..
I would say that in most cases the data is not suitable for UI generation. That's why you almost always put a a layer of logic in between to interpret the DB information to the user. Another thing is that when you generate the UI from DB you will end up displaying the inner workings of the system, something that you normally don't want to do.
But it depends on where the DB came from. If it was created to exactly reflect what the users goals of the system is. If the users mental model of what the application should help them with is stored in the DB. Then it might just work. But then you have to start at the users end. If not I suggest you don't go that way.
Can you look on your problem from application architecture perspective? I see you as another database terrorist – trying to solve all by writing stored procedures. Why having UI at all? Try do it in DB script. In effect of such approach – on what composite system you will end up? When system serves different businesses – try modularization, selectively discovered components, restrict sharing references. UI shall be replaceable, independent from business layer. When storing so much data in DB – there is hard dependency of UI – system becomes monolith. How you implement MVVM pattern in scenario when UI is generated? Designers like Blend are containing lots of features, which cannot be replaced by most futuristic UI generator – unless – your development platform is Notepad only.
There is a hybrid approach where forms and all are described in a database to ensure consistency server side, which is then compiled to ensure efficiency client side on deploy.
A real-life example is the enterprise software MS Dynamics AX.
It has a 'Data' database and a 'Model' database.
The 'Model' stores forms, classes, jobs and every artefact the application needs to run.
Deploying the new software structure used to be to dump the model database and initiate a CIL compile (CIL for common intermediate language, something used by Microsoft in .net)
This way is suitable for enterprise-wide software and can handle large customizations. But keep in mind that this approach sets a framework that should be well understood by whoever gonna maintain and customize the application later.
I did this (in PHP / MySQL) to automatically generate sections of a CMS that I was building for a client. It worked OK my main problem was that the code that generates the forms became very opaque and difficult to understand therefore difficult to reuse and modify so I did not reuse it.
Note that the tables followed strict conventions such as naming, etc. which made it possible for the UI to expect particular columns and infer information about the naming of the columns and tables. There is a need for meta information to help the UI display the data.
Generally it can work however the thing is if your UI just mirrors the database then maybe there is lots of room to improve. A good UI should do much more than mirror a database, it should be built around human interaction patterns and preferences, not around the database structure.
So basically if you want to be cheap and do a quick-and-dirty interface which mirrors your DB then go for it. The main challenge would be to find good quality code that can do this or write it yourself.
From my perspective, it was always a problem to change edit forms when a very simple change was needed in a table structure.
I always had the feeling we have to spend too much time on rewriting the CRUD forms instead of developing the useful stuff, like processing / reporting / analyzing data, giving alerts for decisions etc...
For this reason, I made long time ago a code generator. So, it become easier to re-generate the forms with a simple restriction: to keep the CSS classes names. Simply like this!
UI was always based on a very "standard" code, controlled by a custom CSS.
Whenever I needed to change database structure, so update an edit form, I had to re-generate the code and redeploy.
One disadvantage I noticed was about the changes (customizations, improvements etc.) done on the previous generated code, which are lost when you re-generate it.
But anyway, the advantage of having a lot of work done by the code-generator was great!
I initially did it for the 2000s Microsoft ASP (Active Server Pages) & Microsoft SQL Server... so, when that technology was replaced by .NET, my code-generator become obsoleted.
I made something similar for PHP but I never finished it...
Anyway, from small experiments I found that generating code ON THE FLY can be way more helpful (and this approach does not exclude the SAVED generated code): no worries about changing database etc.
So, the next step was to create something that I am very proud to show here, and I think it is one nice resolution for the issue raised in this thread.
I would start with applicable use cases: https://data-seed.tech/usecases.php.
I worked to add details on how to use, but if something is still missing please let me know here!
You can change database structure, and with no line of code you can start edit data, and more like this, you have available an API for CRUD operations.
I am still a fan of the "code-generator" approach, and I think it is just a flavor of using XML/XSLT that I used for DATA-SEED. I plan to add code-generator functionalities.

Resources