Of course the corollary to this is the
actual implementation of the validation.
As it is now we have additional
restrictions (names and such) because of the POJO-based persistence. It seems
as we allow other mechanisms of persistence (although POJO will still be there
and the preferred mechanism in some existing installs for obvious reasons) some
different restriction might be needed. This means the implementation should
allow to delegate the validation to the repository somehow.
…
Eric
From:
tigerstripe-dev-bounces@xxxxxxxxxxx [mailto:tigerstripe-dev-bounces@xxxxxxxxxxx]
On Behalf Of Eric Dillon
(erdillon)
Sent: Wednesday, February 20, 2008
6:44 AM
To: Richard Craddock (rcraddoc)
Cc: Tigerstripe developers list
Subject: RE: [tigerstripe-dev] RE:
Some questions.
What do you a mean a
“design” J?
Well I guess 2 things
come to mind:
In the EMF world you
won’t be doing doSave() any more. There would be 2 occurrences when a
validation is required:
-
Upon
initial “store(…)” into a IModelRepository. This could throw
an Exception due to the fact that the object you’re trying to store is
invalid.
-
Upon
commit of a TX when trying to change attributes on an object that is already
living in a store. I guess we should rollback the transaction and post the
failure through the official mechanism (not sure what the details are yet with
EMF Transaction for that).
That being said it would
rely on an internal method to “validate/visit” the object (Visitor
pattern) and potentially gather problems/warnings, etc. It would probably be a
good idea to make this method part of the API so you don’t have to
“wait” all the way until you try to commit.
Also, I suspect the
auditor would rely on that too.
Does that make any sense?
Eric
From: Richard
Craddock (rcraddoc)
Sent: Wednesday, February 20, 2008
6:21 AM
To: Eric Dillon (erdillon)
Subject: RE: [tigerstripe-dev] RE:
Some questions.
217970
I agree
with doing it in the context of EMF, but to write a test case, I need to have a
"design" :-)
From: Eric
Dillon (erdillon)
Sent: 20 February 2008 14:14
To: Richard Craddock (rcraddoc);
'Tigerstripe developers list'
Subject: RE: [tigerstripe-dev] RE:
Some questions.
Cool.
More comments below.
Eric
From: Richard
Craddock (rcraddoc)
Sent: Wednesday, February 20, 2008
4:02 AM
To: Tigerstripe developers list;
Eric Dillon (erdillon)
Subject: RE: [tigerstripe-dev] RE:
Some questions.
Eric,
all your
fixes are good.
Item 3 .
Change made.
Item 6.
My bad. IRelationshipEnd already has a getOtherEnd(). no change needed.
Re: bug
217290 - Should this simply throw a TigerstripeException if the type being
attempted to set is invalid?
This
makes me think of a few other things - like if I create anything through the
API, bit don't set a Type - what should the app do? Allow you to save it
anyway? (I think that is what happens now). Maybe we should have some
"minimal requirements" to make an attribute/field/method etc valid ?
[ER>] what’s the correct bug
number… this is not a Tigerstripe bug. I tried some combination but
couldn’t guess J.
I believe we have some validation logic
being triggered through the UI, not sure how it’s hook in the API. If it
is not, it would need to be! I’d prefer to look into this within the
context of the EMF move though unless it is a quick fix.
RC
From:
tigerstripe-dev-bounces@xxxxxxxxxxx
[mailto:tigerstripe-dev-bounces@xxxxxxxxxxx] On
Behalf Of Richard Craddock (rcraddoc)
Sent: 20 February 2008 09:05
To: Eric Dillon (erdillon)
Cc: Tigerstripe developers list
Subject: [tigerstripe-dev] RE:
Some questions.
Hi Eric,
good
work!
I'll be
carrying on today, but have a process question - if you (or anyone else) have
fixed a bug and I'm happy with it should I close it, or de we wait until we
have a formal build with it in?
From: Eric
Dillon (erdillon)
Sent: 20 February 2008 00:38
To: Richard Craddock (rcraddoc)
Cc: Jim Strawn (jistrawn); Duncan
Keysell (dkeysell); 'Tigerstripe developers list'
Subject: RE: Some questions.
Hi
Richard,
See my
comments inline.
Eric
From: Richard Craddock
(rcraddoc)
Sent: Tuesday, February 19, 2008
8:34 AM
To: Eric
Dillon (erdillon)
Cc: Jim Strawn (jistrawn); Duncan Keysell (dkeysell)
Subject: Some questions.
I raised bugs where I could. Heres a
variety of thoughts/questions
[ER>] I’ve addressed 219420,
219444, 219450, 219454, 217823, 217825. This will be in tonight’s nightly
build.
1. What is the option "Cascade
Delete References" for in the Preferences/General tab for ? I've never
noticed it before......
[ER>] I initially couldn’t remember
what this could be, but I remember talking with Chris about this case: when
deleting an artifact from the model that has incoming or outgoing associations,
these associations/relations are currently left “dangling”. This
option mean that all relationships would be removed as well. I am unclear as
what is really implemented, so I would be in favor of removing this option from
the GUI until we can vouch for what it really means L.
2. I think we need to review the
OSS/J settings in the "factory default" profile - the OSS/J specifics
appear unless you turn them off - should be the reverse ?
[ER>] Agreed. The OSSJ settings should
all be turned off by default.
3. On Method we have a method called
getMethodReturnName() - is might be simpler to just have getReturnName()
[ER>] Please make the change.
4. I seem to remember that
*somewhere* in the code you can query an AbstractArtifact to see if it supports
Methods, Constants etc. This might be quite handy to add to the API. And add a
similar thing to say if it has Ends.
[ER>] As discussed briefly on the phone
today, I think it makes sense to provide a way to “introspect” the
artifacts. This will be needed/available from the EMF implementation later on.
I was hoping to get around to doing it today… not sure anymore.
I’ll send you an email if I do finish this tonight.
5. Isn't the refBy stuff really an
OSS/J specific ?
[ER>] Hmmm…. This needs to be
thought thru. It should indeed be considered as an OSSJ extension in the
metamodel, but it is currently embedded quite deeply in the core, so we have
look at the consequences…
6. On an associationEnd - there is
no current method to say if it is the AEnd or ZEnd of a relationship - I'm not
sure exactly what this truly means in context as the navigability are the truly
useful things, but we have had to do some (admittedly simple) checking whenever
we want to get the "otherEnd". Maybe a couple of methods could be
added isAEnd() isZEnd() ?
[ER>] I believe there is a getOtherEnd()
method on the implementation of IAssociationEnd. It should simply be a matter
of pushing this into the IAssociationEnd Interface and it should do the trick?
7. (Warning - Modelling question!) Still on the
associationEnd - we have Multiplicity, but we also have a type which has multiplicity
- the TypeMultiplicity is always 0..1 - should that be 1, or is it really
irrelevant?
[ER>] Yes. This is a bit redundant.
IAssociationEnd exposes a multiplicity, and the IType on that end does too. For
consistency we should probably use the IType one only. Also, we need to look
into migrating the current Enumeration-based multiplicity to support arbitrary
bounds (upperBound, lowerBound).
8. (This is very minor) when I add
an attribute to an artifact it generates the names attriubute0, attribute1,
attriubute2 . If I then switch artifact, it starts at attriubute2 ....
[ER>] Yes, a little annoyance indeed,
maybe there is a “static” somewhere we should remove J.