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.