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.

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.

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.

On Tue, Sep 2, 2008 at 1:07 AM, denstar <[EMAIL PROTECTED]> wrote:

>
> Hi Jared!
>
> Separate files is the goal.  I'm speaking specifically about the generated
> code.
>
> Currently, (or at least last I checked), all the scaffolding
> information is compiled in the one file (scaffolds/Scaffolds.xml),
> whereas the patch that I did for MG2, and that I'll eventually do for
> MG3, -- hmm, can you call it a patch if you never sent it to the
> author? eh.  -- creates separate files for each scaffolded object.
> Heh.  I said "scaffolded" (but that's not important now -- back to the
> task at hand).
>
> Same deal with the generated event config XML.  All on one line, in
> the ModelGlue.xml file -- whereas I'd like to see separate xml files
> for each controller.
>
> Sorry I wasn't very clear, and I'm not sure if I clarified much more,
> but basically I'm talking about the generated XML files.  :]
>
> Thanks,
> :DeN
>
> --
> There is no such thing as a 'self-made' man. We are made up of
> thousands of others.
> George Matthew Adams
>
> On Mon, Sep 1, 2008 at 7:38 PM, Jared Rypka-Hauer wrote:
> >
> > Denny,
> >
> > Not sure what there is to patch. Since MG supports the <include />
> > tag which allows you to include any other propery-formatted ModelGlue
> > XML file (it must be a complete file on its own, so it has to have
> > <modelglue>...</modelglue>), you can keep everything in separate
> > files already, and I do.
> >
> > You can already break things down by site section, by entity, by a
> > random grouping of pages, etc., break controllers apart, whatever...
> > it's up to you how you want to structure your XML, and if you use the
> > DTD you can get tag and attribute assist in all of the files you're
> > working with.
> >
> > So I guess the question is what's to patch in MG that this doesn't
> > already handle?
> >
> > J
> >
> > On Sep 1, 2008, at 8:01 PM, denstar wrote:
> >
> >>
> >> Hi there,
> >>
> >> I've been playing with both event generation and scaffolding, and I've
> >> got a couple of suggestions.
> >>
> >> Well, it's more just one suggestion: split the xml files out into
> >> their own entities.
> >>
> >> Instead of putting the generated event xml in the main modelglue file,
> >> create sub-files and include them in the main one.  Same goes for the
> >> scaffolded stuff, instead of putting it all in the scaffolds file,
> >> split them out into files by object.
> >>
> >> If this sounds good, I'll submit a patch, as I'm going to do it for
> >> myself.  I did it for the scaffolding in MG2 and it really improved
> >> the usability.
> >>
> >> PS - It wouldn't hurt to format the generated xml... I use jTidy for
> >> my own stuff, but that's probably not a cool dependency-- maybe
> >> there's something CF based...
> >>
> >> I've also got some suggestions for structuring the configs for the
> >> actionpacks a little different, but I'll address that in another post
> >> sometime.
> >>
> >> Thanks,
> >>   denny
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
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 .
-~----------~----~----~----~------~----~------~--~---

Reply via email to