After reading your reply, I think that I have misinterpreted the semantics
of the method. So the method requires that the path starts from the next
level below the namespace.
Ok, but as you said, there are inconsistencies in the current API and maybe
I got in the middle of them. My thinking was driven by the fact that paths
are obtained by getPathList(), which returns full paths all the way up to
roots (which may not be models, ok, but they are either a namespace or not
suitable as an argument to getElement). So I thought both methods
(getElement() and getPathList()) should be 'compatible', in the sense that
their use can easily be combined.
As I said before my work gets around extension mechanisms, so suppose we
have saved the path of a given element 'e' from namespace 'ns' as the type
of a TagDefinition 'td':
List<String> ePath =
Model.getModelManagamentHelper().getPathList(me);
Model.getExtensionMechanismsHelper()
.setTagType(td, ePath.toString());
And, later (after a save+close and open project), we want to retrieve the
element. Something like:
String path = Model.getFacacade().getType(td);
path = path.substring(1, path.size()-1);
List<String> ePath = path.split(",");
Model.getModelManagamentHelper().getElement(ePath, ns);
But, this code does not work. We either truncate the path setting the
TagDefinition type (which I think is not a good solution for saving a
model), or we have to truncate the path before passing it to getElement():
List<String> nsPath =
Model.getModelManagamentHelper().getPathList(ns);
ePath = ePath.subList(nsPath.size(), ePath.size());
Ok, you think this is not a big deal, but in the case we don't know the
namespace where the element is, we have to search from roots and do this for
all of them. Still not much?...
Anyway, I thought it would be handy to let getElement() handle at least the
same path level as the received namespace (in the case they match; if they
don't match the behavior is not changed).
Sergio.
PS: I just typed the code directly here, as an example, so there is surely
some error, but you get the idea...
> -----Original Message-----
> From: Tom Morris [mailto:[EMAIL PROTECTED]
> Sent: segunda-feira, 19 de Novembro de 2007 22:38
> To: [email protected]
> Subject: Re: [argouml-dev] Feature Request for
> ModelManagementHelperMDRImpl.getElement(...)
>
> I'd have to review this more carefully to see what the compatibility
> implications are, but I've provided some quick feedback below off the
> top of my head. The existing API was created in an ad hoc fashion by
> encapsulating the original NSUML implementation, so it doesn't always
> seem very logical, but it is very important to maintain compatibility
> with the existing behavior. We can introduce new methods which have
> more logical behaviors if necessary.
>
> On Nov 19, 2007 2:07 PM, Sérgio Lopes <[EMAIL PROTECTED]> wrote:
>
> > the method [...] getElement(List<String> path, Object namespace)
> > does not work if the root of path starts at the same level as the
> namespace.
> > For example, if namespace, is an object 'ns2', whose full path as
> obtained
> > with getPathList() is [model1, ns1, ns2], and path is [ns2, ns3, c1],
> the
> > method does not find the model element 'c1' (assuming it exists).
> > It will find elements when the root of path is a direct children (one
> > level below) the namespace.
>
> The current behavior sounds correct to me. If I lookup ns2 in ns2's
> ownedElements, I won't find it.
>
> > I think it would be useful to support the example above. It would enable
> > searching elements in models (top-level namespaces) providing a full
> path
> > obtained with getPathList(). Can we support that?
>
> I think a better way to allow this would be to allow a null namespace
> argument to signify the root of the repository. Historically, we've
> assumed a single top level root Model, but there can be multiple top
> level ModelElements and they don't have to be Models. That's why
> we've deprecated getRoot() and introduced getRoots() (although not all
> the code yet handles multiple roots/top level packages yet).
>
> > Finally, note that if we call the method with a full path to be searched
> in
> > a namespace that is not a model (top level namespace) the method still
> won't
> >
> > work. Is there any interest in handling these cases?
>
> I don't understand what you're trying to say here. The lookup is by
> definition relative the starting namespace. If you take a complete
> path that goes all the way to the top level and use it to try and
> lookup the element starting in a namespace which is further down the
> tree, it should fail. Can you clarify what you mean?
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
