I suppose I am actuall reitterating what you said earlier. Please
assign CAY-659 to me.
regards Malcolm Edgar
On 2/2/07, Andrus Adamchik <andru..bjectstyle.org> wrote:
> As I mentioned I don't see a problem with comments being done as a
> separate feature (CAY-659). I posted a list of similarities between
> comments and properties in my previous message, but there are
> differences as well.
>
> Anyways, I am +1 on Malcolm's proposal as long as MapLoader can be
> configured to skip or include comments at will. Should we assign
> CAY-659 to Malcolm?
>
>
> > The danger with CAY-400 is the use-cases/requirements are pretty
> > vague, making it hard to dermine what's needed. I think this is why
> > this feature has stalled.
>
> I think this was more of a lack of personal motivation among current
> committers. I can speak for myself - I think this feature is cool,
> but I never needed it badly enough.
>
> Andrus
>
>
> On Feb 1, 2007, at 11:35 PM, Malcolm Edgar wrote:
> > I think the requirements for user properties (CAY-400) and
> > comments/description (CAY-659) are different.
> >
> > While CAY-400 could be used to support comments, and other things like
> > meta-data, I think getting the comments/description done as a modeler
> > enhancement is better done separately. Editing a simple description
> > field will be easier to use than arbitrary lists of user defined
> > properties.
> >
> > The danger with CAY-400 is the use-cases/requirements are pretty
> > vague, making it hard to dermine what's needed. I think this is why
> > this feature has stalled.
> >
> > Adding description fields to the Modeler is a much simpler
> > requirement, which shouldn't be stalled as well.
> >
> > Regarding the design, loading the comments only when using the modeler
> > sounds fine to me. I can't imagine people pasting a Word document into
> > a 30 character length text field, however I could be wrong.
> >
> > regards Malcolm Edgar
> >
> > On 2/1/07, Aristedes Maniatis <ar..sh.com.au> wrote:
> >>
> >> On 01/02/2007, at 9:28 PM, Andrus Adamchik wrote:
> >>
> >> > We are talking about BLOBS of text. Consider people using this for
> >> > javadocs, with each attribute having a 100 char comment field. For
> >> > the model of 50 entities with 20 attributes each, we have (50 +
> >> > 50*20) * 100 = 102K. Not crucial, but still keeping this stuff
> >> > around in runtime seems wrong. Those things add up over time,
> >> > resulting in framework becoming heavier with every new release.
> >>
> >> Not to mention it might contain private notes we may not want in a
> >> public release of a product. I don't want our entity documentation
> >> released to the world.
> >>
> >> How about a velocity(?) script which could strip some parts of the
> >> XML file for deployment? As long as they were easily identifiable, we
> >> could even put a little regex into our main ant build script for
> >> deploying the application.
> >>
> >> On the other hand, a separate config file for comments would make
> >> this easier...
> >>
> >> Ari
> >>
> >>
> >> -------------------------->
> >> ish
> >> http://www.ish.com.au
> >> Level 1, 30 Wilson Street Newtown 2042 Australia
> >> phone +61 2 9550 5001 fax +61 2 9550 4001
> >> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
> >>
> >>
> >>
> >>
> >
>
>
This archive was generated by hypermail 2.0.0 : Fri Feb 02 2007 - 06:01:44 EST