Hi Marcos,
apologies for the last email being a bit negative criticism. I think
that your idea of defining the module profiles with less code is much
better than what we currently have. As you have seen from my proposal
I think that if this is done correctly we could make module profiles
and user defined profiles the same way and both more powerful and
dynamic than what we currently have.
So, I'm happy that you have made this proposal and worked on it to
provide a proof of concept.
>
> hi, do you know how do i do that in eclipse svn?
>
Hi Marcos,
I think you do "right click" on a file in package explorer, then
"compare with", then branch, then select trunk... DISCLAIMER - I
didn't checked this.
>>
>> Where are the automated tests?
>>
>
> easy answer: no automated tests yet
> hard answer: how do i test this???
>
If you consider an integration test, you may place XML file(s) in the
repository and test that these are parsed correctly and the profile
available in the ProfileManager registered profiles.
>> The XML processing is a bit better (see PluginProfileLoaderImpl.java) than
>> the one devised for ProfileConfigurations (see
>> ProfileConfigurationFilePersister.java), but, I would like to see it less
>> hard coded, meaning, we could define a XML schema, generate parsing code
>> from there and parse and validate the XML files containing the profile
>> definitions.
>> In a project I worked before, castor did a great work at this, enabling the
>> generation of the java code from a XML schema and validation of the XML
>> files against the schema.
>>
>
> hi, a part from the schema, how would this improve the current code?
> if i'm still going to look for the attribute "X" in the tag "Y" to
> fill the values in my objects what is the point?
>
That is why I referred castor (www.castor.org). It generates Java
classes from a schema and parses the XML into instances of those
classes. So, you would just receive an instance of class Y with an
attribute x. It would also enable validation of XML files.
>> How are the FormatingStrategy and the DefaultTypeStrategy intended to be
>> implemented in the plugin variant of the profiles?
>>
>
> i really don't know, these things existed before my profile's works
> last year and i never saw their utility...
>
I also don't know about FormatingStratety, but, the intent of
DefaultTypeStrategy is very interesting, since it allows the profile
author to specify the default types of return values, parameters and
attributes.
>> As a generic comment, I see the usage of a new XML file format as negative.
>> We already have the XMI format. UML is an extensible modeling language and
>> it allows tagged values to be associated to stereotypes. Thus, we may
>> associate a figure file to a specific stereotype using a tagged value in the
>> stereotype (see FigNodeStrategy). We may define values for three Tag
>> Definitions - DefaultAttributeType, DefaultParameterType and
>> DefaultReturnType - in the model that is the a profile, and, where the types
>> are defined, or, being the profile dependent on another profile where the
>> types are defined.
>>
>
> i agree with you, we could do this by defining a profile of our uml extension
> (in this case, just for documentation) and use the tagged values for defining
> the things in the xml and the constraints for critics,
>
> indeed, i think we would still need to define a xml and these things
> for lower level
> profiles (the ones providing java code, for example, since not everything can
> be specified in ocl)
>
If you want Java code in a XML file, it would require users to have
always a java compiler. I think that the code should be in a
scriptable language (e.g., JavaScript comes bundled in JRE 6) and this
would be possible to execute by feeding the code into the interpreter.
Nevertheless, placing the code in a tagged value (see the
documentation tagged value as an example) is possible, therefore
removing the need for an external XML file in a proprietary format.
>> How about critics, couldn't we also place them in a XMI file? If they are
>> stored as OCL we sure can. If they are saved as a scripting language, these
>> could be placed in a special tagged value, closely associated to some class
>> or DataType for which they are meaningful.
>
> yes... the idea is that the critics could be implemented in any language
> what i have implemented was what is currently supported: critics in Java.
>
> ocl and these fancy things is the next step ;)
>
>>
>> Defining FormatingStrategies could be done in the same way as critics,
>> i.e., by placing code in the XMI file which would have to follow a specific
>> convention...
>>
>> This would allow users of ArgoUML to use ArgoUML to extend ArgoUML by
>> defining profiles which would have the same functionality as the module (or
>> plugin) profiles and the module profile developers would use also ArgoUML
>> for the same task. Even the PluginProfileModule class could go away if we
>> follow the idea of /design by convention/ and specify that there is a
>> mechanism in the ArgoUML core that checks the modules to look for profiles
>> in a specific directory of the jar.
>
> i think this is already there. currently the user has two options: (1)
> a user defined profile
> and (2) a plugin defining a profile
>
> we can't leave out the option (2) because not all critics can be
> specified in ocl.
>
> in my opinion we should move more things to the xmi files, in this
> case the paths for the fignodes...
> the ocl critics will be there when we have ocl in argouml (and ocl
> refering to the metamodel, instead to the model!
> this is the most difficult part)
>
> maas
>
I think and I'm arguing that we may place everything in the XMI file.
Using tag definitions we can create a profile for defining "enhanced"
ArgoUML profiles (or plugin ArgoUML profiles if you prefer), say
argouml-enhanced-profiles.xmi.
This would define a stereotype named PicturedStereotype applicable to
stereotypes with the tag definitions bigIconFileName and
smallIconFileName. The convention on where to place the files would be
to look for these files in the same directory where the XMI files is
contained.
Another Tag Definitions from argouml-enhanced-profiles.xmi, applicable
to a model and defined in the context of stereotype
<<ArgoUMLEnhancedProfile>> would be named defaultAttributeType,
defaultParameterType and defaultReturnType and would enable a profile
author to specify the appropriate types that his profile defines as
defaults for attributes, parameters and return parameters,
respectively.
In the same way we could define tag definitions associated with
formatting that could contain in the first line a tag that defines the
scriptable language to be used to execute the code and the remaining
of the string as code that would be callable using and instance of the
interpreter of that language. Note that this might be a bit more
complicated than what I propose here, but, the idea is understandable,
I hope.
<script type="text/javascript">
function foo(name) {
return "Hello " + name + "!";
}
</script>
Off course, a specialized editor could be developed or integrated,
but, the basic thing is possible if we can make a multi-line text edit
box available for these special tagged values. - Note that this should
already be available for OCL and it is already available for
documentation tagged values.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
