Hi Hugh,
I am not in my brightest state of my mind at the moment, so I may deny that
the following belongs to me when I wake up in the morning...
I think I can build a GUI automatically without instantiating a single RM
class at all. The reason is; the archetype gives you all the information
about
Thanks Tom,
This is a point for which I have no comments :)
Kind regards
Seref
On Wed, Nov 26, 2008 at 9:27 AM, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
Just one small problem - the built RM instance structure usually
deviates in some way from the archetype structure, e.g.
Hi Seref,
I think 'lifecycle' is not the term you want, since most people use that
to mean 'authoring lifecycle' i.e. the authoring, review, approval
history of an archetype. Here we are talking about the runtime usage of
an archetype. If I understand correctly the question it is: can the
Hi Tom,
Thanks for the correction of the term. Yes I'm referring to runtime usage of
archetypes.
After taking a look at the RM class code in ref. impl. I guess it is safe to
say that some RM classes seems to check for proper values, and that's a
reason to create instances of them. I guess this is
Seref Arikan wrote:
(...)
Things become interesting after this point. In the context of the java
reference impl. and immutable rm classes, we can now create rm
instances since we now have data, and we can persist them. If we were
think of the simplest use case of just storing
Hi,
The term lifecycle may not be appropriate for archetypes, and suggestions
for a better term are more than welcommed.
Assuming that we constrain our interest only to a set of information
encapsulated in a single archetype, would you provide the technical
lifecycle you can imagine, for an
6 matches
Mail list logo
