I cannot agree that the learning curve is steeper for WA extensions, but perhaps I was more savvy by the time I started using WA. The WA assist code is 'lighter' and more customizable. The problem I have is that I consistently have to do too much customization for every implementation.
I think WA is the best alternative to ADDT and the best tool available (with any debate about going to an MVC framework put aside for now :o)
A well designed, easy to use trigger/transaction concept would be great, but much of it can be done now by organizing the WA & custom actions you include on a page.
What I think we need to take this to ADDT's level (and hopefully with improvements on the old code) is a number of things that seem basic to DB management and CMS which I did not see on Ray's list. It is not intended to be a criticism, but we have to be honest about the shortcomings if we are going to make progress. I have implemented all of these things on my sites. I just often start to wonder whether or not I am saving any time with WA over coding the whole thing from scratch when this many modifications have to be made time and time again.
- Sortable lists by drag and drop or arrow buttons. The usefulness of this is pretty self explanatory.
- Recordset management over table management. So you can edit and manage subsets of a table or bring in joined fields for the display. If we could even find a way to edit the joined tables, that would be awesome but perhaps over the top.
- Maintain parameters. This really relates to recordset management. By this I mean if I use a url parameter to distinguish the recordset of the "results" page (wish it were index instead of results), I have to manually ensure that the url parameter is maintained throughout the process. When I have tried to pass the query string, I get duplicates and the URL just keeps growing, acquires duplicates, and is still present when you leave that editing process.
- Read <?php echo $this; ?>. I often have to write code in WA PHP syntax because plain PHP breaks the extension. I know that may be a tall order, but it would be nice.
- Cleanup after itself. I would rather decide that I need to keep the insert id alive than have every insert id and other session values maintained rather than manually unset them every implementation. I usually organize the back-end with folders: faq, gallery, pages, etc. Each contains the DA files to manage that application, and they generally have the same names: index, delete, update, etc. I frequently encounter data collisions if they are not cleared. If the user just inserted a record... well that was a few actions ago. The first big encounter I had with this was with the search function because all my files were called "index" (sorted by folders). I had to figure out why all my lists had sql errors. It was because every list was looking for WADbSearch1_index.
- Search indication and form population with search. When a user searches, WA does not indicate the recordset is filtered and does not repopulate the form so the search can be refined. I wrote my own but have to implement it each time.
- Better email contemplating system. I find it very easy to break the template system. Anything more sophisticated than duming the form values onto a table has to be written just so and the code view is just asking for trouble. I would think just a plain web page file with custom replace syntax like [[name]] would be better. I just tried to include a file and I needed to write it exactly as <?php echo (file_get_contents("http://".$_SERVER['SERVER_NAME']."/inc/header.php")); ?> to not break the template.
- Lose spry and go to jQuery. I am still using DW3, but I think Spry is going the way of ADDT. I think jQuery is a lot easier to work with.
- Fix the explode issue in WADA for the bar | character. The extension should handle the encoding and unencoding of the character.
There are probably some more issue on my mind but those seem like the big ones. Rollback was great in ADDT transactions. You did not have to worry about what kind of table/db you were using to get the benefit of transactions, but I think that also may have contributed to the weight and cpu usage since it had to maintain a lot of information to roll the transaction back. If we could still get that in a lighter form, that would be great.