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 <[EMAIL PROTECTED]> 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
