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