Leo Simons wrote:
Stefano Mazzocchi wrote:
This is not a rant, but constructive criticism.
1) as I mentioned already, I think that having gump (or forrest or whatever) generate static HTML pages creates more problems than it solves. I think we should move the architecture with something like this
metadata -> gump -> database -> jenny -> user
I agree. Keep in mind that
metadata -> gump -> database -> jenny <-\ ^ | | | \---------- user <--------------------/
Yes, I thought about it and it might require some thinking overhere too.
First of all: for that to work, all gump metadata must reside in the same repository... or, even better, not reside in a repository at all but just reside in a database.
Cocoon build system, for example, depends directly on the gump module file and it's very unlikely for that to change any time soon. At the same time, if gump gave the same XML file from a URL, we could simply download it at build time and it would not be such a big issue (cocoon needs it for the blocks not for its core).
So, what do you guys think: should gump metadata still reside in xml files or should it reside in a database and we have a web application on top that takes care of managing it?
it's worth thinking about workflow if you split things up, before you split things up.
True.
It could be that you want to have a "Jane" besides "Jenny", where Jane is used for modification of the metadata and execution of complex workflow activity. Or whatever.
Another minor comment: let's make sure we *brand* the whole thing as gump, not just a part of it.
All right forget about gump/jenny, it was just an example.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
