I was actually focusing on your inclusion of the event generation code in this request, not really the scaffolding since I don't use it. That's why I was saying it would be difficult to do: if I generate an event called "user.list" via the URL, it could be rather dangerous to assume that I want a MG XML file named "user.xml" or something. I might not want to call it that, or I might already have an XML file that contains user stuff that is named "admin.xml" that does lots of admin-related things for users plus more, or I might have the file in my own location (config/includes/user.xml), or I might not want it in a separate XML file at all.
On Tue, Sep 2, 2008 at 4:16 PM, denstar <[EMAIL PROTECTED]> wrote: > > On Tue, Sep 2, 2008 at 6:07 AM, Brian Kotek wrote: > > I would say that this would probably cause more confusion than good. > While > > you might like having separate XML files, I have to say I doubt most > people > > would. So I would say the existing behavior should stay as it is. For > people > > with small to medium-sized apps, I believe they prefer to have a single > file > > to deal with. Since it is trivial for people to go in and move desired > > chunks of XML into separate files if they want to, this really isn't an > > issue that I can see. > > From limited testing (2 people), they *all* (heh) like the separate > files for scaffolded objects. Even for small apps. > > It especially helps developers new to the framework. Really, I swear. > They like it better more organized. > > Not one of the 2 people said they liked it better all in one file. :] > > > Also, from an implementation perspective, having the core attempt to > figure > > out which child XML file some generated code goes into would be > exceedingly > > difficult. People can name the XML includes anything they want. There's > no > > way the core could know where to insert something even if using child > files > > was actually attempted. > > Actually, since we're linked to the object name, and not some > arbitrary file, it's pretty much the exact same as it is now, but with > separate files, like so: > > -Scaffolds.xml > -- include personObject.scaffold.xml > --- personObject.scaffold.xml > -- include addressObject.scaffold.xml > --- addressObject.scaffold.xml > > See, nothing confusing, and I'm not talking about this as a pie in the > sky type of deal-- I've done it, and it works fine. As far as MG is > concerned, all it's doing is pulling in Scaffolds.xml, same as always. > Since both Scaffolds.xml and the included sub-files are re-generated > when you re-scaffold, there's nothing to keep track of, so to speak. > > > I do agree that formatting the generated XML would be nice though. There > is > > a UDF at CFLib.org called XMLHumanReadable() that does a pretty good job > of > > formatting XML. I've used it with good results when generating ColdSpring > or > > Transfer XML files. > > Excellent! I've enjoyed jTidy, because it does other stuff too, but > tossing in a CFC would be best, I reckon. > > @cfChuckstar : The built in (with J2EE version) Eclipse XML tools do > swell at formatting the code too... but why not save the environment, > and reduce electron/mouse abuse? :-) > > Is what I'm talking about getting any clearer? It's not really all > that and a bag of chips, but it has helped -- especially for me, a > 24hr coder, who doesn't especially like culling through a big ass file > to get what I want at 4AM. [: > > -- > Francis Webb is easily our greatest poet and one of the greatest poets > in the world but he's hardly ever mentioned. > Robert Adamson > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "model-glue" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/model-glue?hl=en For more about Model-Glue, check http://www.model-glue.com . -~----------~----~----~----~------~----~------~--~---
