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 - 05:35:50 EST