Re: [transfer-dev] Application XML (Was: Automatic Generation of Transfer XML)

[Brian Kotek]

It sounds like a bold idea but I don't think it would work in practice. First, that XML file would be gigantic and would take a really long time to write. The whole reason I was generating the XML for Transfer is that I don't want to write it. This would put me back to square one, especially since I already generate my ColdSpring XML config from UML.

Second, attempting to write something that would in turn generate ColdSpring, Transfer, and Model-Glue config files would really be blurring the lines between totally separate things. Transfer is an ORM for your database. ColdSpring is an IOC container for your model. Model-Glue is the application controller. Because they deal with such different pieces of an application, I think it would be really, really hard to write something that encompassed all of this (much harder than just writing the three config files separately). And if it would be meant to do even more (Reactor? Fusebox? LightWire?), the XML would have to be so generic and handle so many possible variations that I just don't see how it could work.

I'm interested to hear if anyone agrees or disagrees. Not to rain on your parade Jonathan. Feel free to give it a shot and report your results.

On 9/5/07, Jonathan Logue <jonath...@gmail.com> wrote:

Hi Everyone,

Doesn't it seem a little backward to be introspecting the DB to get
config files? What if there were a standard XML application definition
schema which also included the database definition. This file could be
used to describe not only the structure of the database, but also the
relationships between entities (similar to the Transfer). It could
also include data used by the application for business logic or
presentation of forms, etc. This information could be used to generate
config files for Transfer, ColdSpring, MG, etc. It could also be used
to generate the DB. Any change to the application definition schema
could trigger updates to the database and any generated code or config
files that were mapped and would include the ability to turn pieces on
and off. The huge upside would be that the application definition
schema would be framework agnostic and could also be used by
developers wanted to build custom frameworks. We could also begin to
develop widgets and components that read the defintion file and allow
developers to drop in some really cool opensource modules. Just
thinking out loud.

Has anyone else thought about this approach or started developing such
a beast? Does something already exist that I am not aware of?

Jonathan

[Peter Bell]

Hi Brian,

It works just fine in practice - it’s how I gen all my sites and have done for a while now.

I have a dynamic framework that consumes a collection of XML files which allows for overloading of functionality with custom methods. One XML file per business object is used to describe properties, relationships, default values, initial data, validations and class methods (getNewUsers(), etc) declaratively. One XML file per controller is used to describe the default action for the controller together with a collection of parameterized controller actions which are described using XML. Any controller methods that can’t be described in XML are put into a cfc for that controller and at runtime the controller cfc looks for custom methods and XML defined methods so it is easy to merge metadata described methods and hard coded ones.

Then there are custom data types to handle transformations, validations, display rules and form editing rules for each property, and templates which handle the layouts together with view helpers which do some of the heavy lifting often required in views.

I find that “bluring the line” rocks as it is really a matter of raising the level of abstraction by describing declaratively the functional requirements for the object model and the interface, and using templates for describing the views. There are LOTs of details to get right to do this. Our system includes versioning, rollback, auditing, support for multiple content areas, a pseudo-page controller to make it easier to reuse functionality on different “pages” and a bunch of other patterns. It also has import, export and I’m working on a collection of wizard and reporting DSLs as well, and I’m also developing a system so as the grammars of the DSLs evolve I’ll be able to automatically transform statements in one version of a DSL to another version – whether using XML transforms or automated data transforms against databased metadata – it’s really pretty cool.

To put things into perspective, later this month we’re going to start selling web apps retail with a new slant: We build it. If you like it, you buy it. We find we can now create pretty rich apps in less time than it used to take for us to write a proposal and I’m betting our closing ratio will be higher (if you had the choice between a built app or a proposal – which would you pick?!). Of course, we also have a whole other thing going on to allow for reuse of metadata by generating the XML files based on common packages that have essential and optional metadata and a decision support system to allow a non-technical specifier to answer a set of questions to associate the appropriate optional metadata to any given project, but I can say from experience of building close to 100 projects in various versions of this tool that the approach works and is radically faster. Real trick is to provide multiple customization points so you merge feature modeling with a decision support system, a collection of DSLs for declaratively describing application functionality and a really easy way to drop in custom code. Build that on top of a smart, well architected framework and you can build amazingly rich apps in only a few hours.

Definitely better than working for a living *grin*

Of course, provisos apply. We do NOT include support for non-functional requirements, so if you need to guarantee a given number of users will be supported, the system is only a starting point. There are many heuristics we use which are good enough with a few tens of thousands of records but you’d want to manually overload some of the DAO code (which is easy to do) if you’re dealing with millions. As always with DSLs, some projects fit the languages better than others so for some projects it’ll generate a complete solution and for others it might be close to useless, but for the kind of Small to Mid-sized Business content management, e-commerce and secure extranet/intranet systems we generate, it is surprising how little code I have to write for the average app (and of course, it gets better every month as I make the DSLs more expressive).

Best Wishes,
Peter

[Jonathan Logue]

Hey guys. Sorry, I did not see the conversation had moved.

Brian, all fair points. It was already raining when I started the
parade ;-) I am not really interested in merging all the various
frameworks together, but managing configuration and code generation
better to reduce inefficiencies. So, if I need to add a column to the
database, I don't want to have to write in that change 6 places or go
back to a code generation tool and reproduce code for several
different purposes. I should be able to add it to the schema and press
a button to have all the standard methods and config files updated
with the change along with the addition of the column to the database.
As for the scope of the project, I will only support one technology
stack to start with and go from there.

This is an experiment for me. I am not confident that any attempt of
mine at doing what I am suggesting will have a happy ending. However,
I really feel that it is a worthy goal. I have started and will see
where this goes. At the least, it will help me on my current project,
but my hope is that I can produce something that will help other
people as well. My approach is to have a utility application that
allows you to manage the application schema using a browser if you so
choose. A better implementation would be to do this as an Eclipse
plugin, but that is not something I have time or the expertise to take
on.

Peter, it sounds like you might be a good consultant for me ;-) Your
project sounds very interesting.

I will come back in a week or two with an update.

-J