Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [emf.validation.ocl] Custom EnvironmentFactory for OCL constraints
|
Re: [emf.validation.ocl] Custom EnvironmentFactory for OCL constraints [message #62431 is a reply to message #62405] |
Mon, 20 November 2006 23:47 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Radek,
Unfortunately, this would mean specifying a lot of <parameter> elements in
the plugin.xml, always with the same value. How about defining your own
'constraint language' on the org.eclipse.emf.validation.constraintParsers
extension point, that uses a more appropriate language?
Also, as the number of constraints to be provided grows, the plugin.xml will
become difficult to manage. You may even want to consider implementing a
more efficient format for defining the constraints and registering a
dynamic constraint provider that makes them available at run-time, without
all of the messy plugin.xml.
Cheers,
Christian
Radek Dvorak wrote:
> Hi,
>
> Currrently, OCL constraints defined by using
> 'org.eclipse.emf.validation.constraintProviders' extension point
> use the default EnvironmentFactory.ECORE_INSTANCE.
>
> Could there be a support for providing a custom EnvironmentFactory to be
> used for OCL constraints defined by this
> extension point?
> I have noticed that the constraint definition may contain a <parameter>
> element, which can hold additional
> constraint-language-specific meta-data. Perhaps, this could be a way how
> to identify the EnvironmentFactory.
>
> Regards,
> /Radek
|
|
|
Re: [emf.validation.ocl] Custom EnvironmentFactory for OCL constraints [message #62455 is a reply to message #62431] |
Tue, 21 November 2006 17:04 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Radomil Dvorak![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=dvorak.radek%40gmail.com) Messages: 249 Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Thanks, for the response.
Ok, doing it by using the parser is fine.
Initiallly, I was thinking about a special constraint-language and its
parser.
I just did not like to duplicate quite some code doing nearly the same but
with a different env. factory. :)
But no code for reuse, everything internal. Something like public
(AbstractOCLModelConstraint base + abstract EnvironmentFactory
createEnvFactory())
might be helpful.
That's why I rather found that as something parameterizable.
What I find more troublesome is providing a custom dynamic constraint
provider, which I wanted to
to use to load constraints from an ecore model instance.
The reason is that all the currently supported parsers rely on
IXmlConstraintDescriptor which makes their
reuse with other providers impossible. This way, the parsers depend on the
type of persistence
chosen by a concrete provider.
Also, it seems to me that the XmlConstraintProvider class contains some of
the generic functionality which could be useful in
the AbstractConstraintProvider class to reduce the effort in implementing
specific providers.
Sorry for my laziness, which drives me to look for the easiest way to do
things :)
Or perhaps, I have not fully understand everything.
Regards,
/Radek
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:ejter0$sq9$1@utils.eclipse.org...
>
> Hi, Radek,
>
> Unfortunately, this would mean specifying a lot of <parameter> elements in
> the plugin.xml, always with the same value. How about defining your own
> 'constraint language' on the org.eclipse.emf.validation.constraintParsers
> extension point, that uses a more appropriate language?
>
> Also, as the number of constraints to be provided grows, the plugin.xml
> will
> become difficult to manage. You may even want to consider implementing a
> more efficient format for defining the constraints and registering a
> dynamic constraint provider that makes them available at run-time, without
> all of the messy plugin.xml.
>
> Cheers,
>
> Christian
>
>
> Radek Dvorak wrote:
>
>> Hi,
>>
>> Currrently, OCL constraints defined by using
>> 'org.eclipse.emf.validation.constraintProviders' extension point
>> use the default EnvironmentFactory.ECORE_INSTANCE.
>>
>> Could there be a support for providing a custom EnvironmentFactory to be
>> used for OCL constraints defined by this
>> extension point?
>> I have noticed that the constraint definition may contain a <parameter>
>> element, which can hold additional
>> constraint-language-specific meta-data. Perhaps, this could be a way how
>> to identify the EnvironmentFactory.
>>
>> Regards,
>> /Radek
>
|
|
|
Re: [emf.validation.ocl] Custom EnvironmentFactory for OCL constraints [message #62479 is a reply to message #62455] |
Tue, 21 November 2006 23:45 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Radek,
Don't worry about laziness. I think what you'relooking for is an API that's
easy to use! :-)
See some reponses in-line, below.
Cheers,
Christian
Radek Dvorak wrote:
> Hi Christian,
>
> Thanks, for the response.
> Ok, doing it by using the parser is fine.
>
> Initiallly, I was thinking about a special constraint-language and its
> parser.
> I just did not like to duplicate quite some code doing nearly the same but
> with a different env. factory. :)
> But no code for reuse, everything internal. Something like public
> (AbstractOCLModelConstraint base + abstract EnvironmentFactory
> createEnvFactory())
> might be helpful.
> That's why I rather found that as something parameterizable.
I'm not sure that one should really want to re-use the current
implementation of the oee.validation.ocl plug-in. :-) It's still using
some of the oldest and least friendly of the OCL parsing APIs, and it is so
small that cleaning it up and factoring out an API would hardly be worth
the effort. If you'd like, you can raise an enhancement request, and we'll
see what can be done. I would like to clean it up a bit if the
opportunity, but I don't know about adding any API. Of course, if you'd
like to contribute a patch ...
>
> What I find more troublesome is providing a custom dynamic constraint
> provider, which I wanted to
> to use to load constraints from an ecore model instance.
> The reason is that all the currently supported parsers rely on
> IXmlConstraintDescriptor which makes their
> reuse with other providers impossible. This way, the parsers depend on the
> type of persistence
> chosen by a concrete provider.
Quite right. What might be needed is something like:
- a new IConstraintParser interface with a that accepts an
IConstraintDescriptor and a Map of parameters (name/value pairs).
- relaxation of the constraintParsers extension point's type restriction
to support either type
- IXmlConstraintParsers (legacy implementations) will continue to
function, supporting only IXmlConstraintDescriptors
- IConstraintParsers support any constraint-provider implementation that
can supply it the parameters that it needs.
That's just what occurs to me on the spur of the moment. Would you mind
raising a bugzilla? I think this would be a bug, not an enhancement (it's
a design flaw). I believe that with this problem resolved, a custom
constraint language ("GMF-OCL"?) and custom constraint provider will be the
best solution for you.
> Also, it seems to me that the XmlConstraintProvider class contains some of
> the generic functionality which could be useful in
> the AbstractConstraintProvider class to reduce the effort in implementing
> specific providers.
I'm not sure that there's much in here to re-use. It's mostly about loading
constraints from IConfigurationElements ...
>
> Sorry for my laziness, which drives me to look for the easiest way to do
> things :)
> Or perhaps, I have not fully understand everything.
>
> Regards,
> /Radek
>
<snip>
|
|
|
Re: [emf.validation.ocl] Custom EnvironmentFactory for OCL constraints [message #62524 is a reply to message #62479] |
Wed, 22 November 2006 16:00 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Radomil Dvorak![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=dvorak.radek%40gmail.com) Messages: 249 Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
I have inserted yet another level of in-line comments. (hopefully can be
parsed...)
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:ek032r$o2d$1@utils.eclipse.org...
>
> Hi, Radek,
>
> Don't worry about laziness. I think what you'relooking for is an API
> that's
> easy to use! :-)
>
> See some reponses in-line, below.
>
> Cheers,
>
> Christian
>
>
> Radek Dvorak wrote:
>
>> Hi Christian,
>>
>> Thanks, for the response.
>> Ok, doing it by using the parser is fine.
>>
>> Initiallly, I was thinking about a special constraint-language and its
>> parser.
>> I just did not like to duplicate quite some code doing nearly the same
>> but
>> with a different env. factory. :)
>> But no code for reuse, everything internal. Something like public
>> (AbstractOCLModelConstraint base + abstract EnvironmentFactory
>> createEnvFactory())
>> might be helpful.
>> That's why I rather found that as something parameterizable.
>
> I'm not sure that one should really want to re-use the current
> implementation of the oee.validation.ocl plug-in. :-) It's still using
> some of the oldest and least friendly of the OCL parsing APIs, and it is
> so
> small that cleaning it up and factoring out an API would hardly be worth
> the effort. If you'd like, you can raise an enhancement request, and
> we'll
> see what can be done. I would like to clean it up a bit if the
> opportunity, but I don't know about adding any API. Of course, if you'd
> like to contribute a patch ...
True, not much to re-use in terms of the number of lines, but provided that
implementing
OCLModelConstraint + parser for every new flavor of OCL is the only way
how to support custom EnvironmentFactory, it would be nice if takes just a
few lines of coding. :)
Could you please review the patch at :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=165458 ?
I believe, at least OCL parsing, caching + the life-cycle management of the
parsed OCL AST
could be re-used. Not much, but boring to repeat :)
>>
>> What I find more troublesome is providing a custom dynamic constraint
>> provider, which I wanted to
>> to use to load constraints from an ecore model instance.
>> The reason is that all the currently supported parsers rely on
>> IXmlConstraintDescriptor which makes their
>> reuse with other providers impossible. This way, the parsers depend on
>> the
>> type of persistence
>> chosen by a concrete provider.
>
> Quite right. What might be needed is something like:
>
> - a new IConstraintParser interface with a that accepts an
> IConstraintDescriptor and a Map of parameters (name/value pairs).
> - relaxation of the constraintParsers extension point's type restriction
> to support either type
> - IXmlConstraintParsers (legacy implementations) will continue to
> function, supporting only IXmlConstraintDescriptors
> - IConstraintParsers support any constraint-provider implementation that
> can supply it the parameters that it needs.
May be, I have not state it clearly, but it solves only part of the problem.
A problem still remains in the case I want to implement a provider which
provides not only the constraints parsed by the new parser interface
but also the constraints parsed by the legacy parsers.
I think, it would be great if the constraint provider could load all the
supported
constraints, but let's say, just from a different storage.
I have raised a bugzilla:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=165455
> That's just what occurs to me on the spur of the moment. Would you mind
> raising a bugzilla? I think this would be a bug, not an enhancement (it's
> a design flaw). I believe that with this problem resolved, a custom
> constraint language ("GMF-OCL"?) and custom constraint provider will be
> the
> best solution for you.
>
>> Also, it seems to me that the XmlConstraintProvider class contains some
>> of
>> the generic functionality which could be useful in
>> the AbstractConstraintProvider class to reduce the effort in implementing
>> specific providers.
>
> I'm not sure that there's much in here to re-use. It's mostly about
> loading
> constraints from IConfigurationElements ...
I think, that selecting live/batch constraints from those loaded by a
provider
and using a constraint Proxy for lazy initialization of the actual
implementation
might be a common functionality.
What seems to me specific is how constraint descriptors are loaded.
Could you please take a look at the patch attached to this post?
I have not created any bugzilla as I have a feeling I have not convinced you
:)
>>
>> Sorry for my laziness, which drives me to look for the easiest way to do
>> things :)
>> Or perhaps, I have not fully understand everything.
>>
>> Regards,
>> /Radek
>>
>
> <snip>
|
|
|
Re: [emf.validation.ocl] Custom EnvironmentFactory for OCL constraints [message #62539 is a reply to message #62524] |
Wed, 22 November 2006 23:42 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Radek,
I have severely edited the text, this time. ;-)
Radek Dvorak wrote:
<snip>
> True, not much to re-use in terms of the number of lines, but provided
> that implementing
> OCLModelConstraint + parser for every new flavor of OCL is the only way
> how to support custom EnvironmentFactory, it would be nice if takes just a
> few lines of coding. :)
> Could you please review the patch at :
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=165458 ?
> I believe, at least OCL parsing, caching + the life-cycle management of
> the parsed OCL AST
> could be re-used. Not much, but boring to repeat :)
True enough! The patch that you attached looks good to me.
<snip>
>> Quite right. What might be needed is something like:
>>
>> - a new IConstraintParser interface with a that accepts an
>> IConstraintDescriptor and a Map of parameters (name/value pairs).
>> - relaxation of the constraintParsers extension point's type restriction
>> to support either type
>> - IXmlConstraintParsers (legacy implementations) will continue to
>> function, supporting only IXmlConstraintDescriptors
>> - IConstraintParsers support any constraint-provider implementation that
>> can supply it the parameters that it needs.
>
> May be, I have not state it clearly, but it solves only part of the
> problem. A problem still remains in the case I want to implement a
> provider which provides not only the constraints parsed by the new parser
> interface but also the constraints parsed by the legacy parsers.
> I think, it would be great if the constraint provider could load all the
> supported
> constraints, but let's say, just from a different storage.
I think that this is something that your provider would have to do. Your
constraint provider is responsible for creating constraints by asking the
ConstraintFactory to parse IXmlConstraintDescriptors. Under the changes
that I outlined, above, this would still be the case (only that the
constraint descriptor would be a more general type). If you want to access
legacy constraint languages, you would have to provide
IXmlConstraintDescriptors.
The problem with this, though, is that you will have to supply an
implementation of IConfigurationElement to the descriptors, for the
IXmlConstraintParsers to read their input in this form. This is an Eclipse
API that you probably don't want to implement, because clients are not
supposed to implement it (and it changes with every new OSGi update).
<snip>
> I think, that selecting live/batch constraints from those loaded by a
> provider
> and using a constraint Proxy for lazy initialization of the actual
> implementation
> might be a common functionality.
> What seems to me specific is how constraint descriptors are loaded.
> Could you please take a look at the patch attached to this post?
> I have not created any bugzilla as I have a feeling I have not convinced
> you
> :)
That's a good point. This patch looks OK, too, though you'll have to raise
a new enhancement request and attach it, as you say. It's just a pulling
up of existing functionality into the existing abstract provider.
Thanks for doing all of this leg-work!
Cheers,
Christian
|
|
|
Re: [emf.validation.ocl] Custom EnvironmentFactory for OCL constraints [message #62610 is a reply to message #62539] |
Thu, 23 November 2006 17:36 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Radomil Dvorak![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=dvorak.radek%40gmail.com) Messages: 249 Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Thanks, I have raised the enhancement
https://bugs.eclipse.org/bugs/show_bug.cgi?id=165661
You are right, I would like to avoid implemeting IConfigurationElement.
Not sure if it's feasible, but would be great, if there is a contract that
the IXmlConstraintParser is considered a legacy interface and all newly
introduced
constraint-languages would be pluged-in using the new IConstraintParser.
If yes, I would implement the new IConstraintParser for the few currently
available languages
rather then IConfigurationElement. AFAIU, ConstraintFactory would then
provide a way
to use also IConstraintParsers.
Personally, I have a feeling that if the general IConstraintDescriptor
interface also provided
String getParameterValue(String name); // the parser specific params
String getJavaClass();
, there would be no reason to have IXmlConstraintDescriptor but only
XmlConstraintDescriptor(impl of IConstraintDescriptor), which would just use
the data parsed from plugin.xml.
All other non-Xml... providers could use their own IConstraintDescriptor
impl
and parsers might have no dependency to IXmlConstraintDescriptor.
I just wonder, if there is something I could have overlooked.
Clearly, I am aware it is an API change, but I also think it could be solved
without breaking
the API contract for the current clients.
If this is of low priority and no special effort is worth it, I would be
more then willing to contribute
a patch ;-).
Regards,
/Radek
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:ek2n9f$j8p$1@utils.eclipse.org...
> Hi, Radek,
>
> I have severely edited the text, this time. ;-)
>
>
>
> Radek Dvorak wrote:
>
> <snip>
>
>> True, not much to re-use in terms of the number of lines, but provided
>> that implementing
>> OCLModelConstraint + parser for every new flavor of OCL is the only way
>> how to support custom EnvironmentFactory, it would be nice if takes just
>> a
>> few lines of coding. :)
>> Could you please review the patch at :
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=165458 ?
>> I believe, at least OCL parsing, caching + the life-cycle management of
>> the parsed OCL AST
>> could be re-used. Not much, but boring to repeat :)
>
> True enough! The patch that you attached looks good to me.
>
>
> <snip>
>
>>> Quite right. What might be needed is something like:
>>>
>>> - a new IConstraintParser interface with a that accepts an
>>> IConstraintDescriptor and a Map of parameters (name/value pairs).
>>> - relaxation of the constraintParsers extension point's type
>>> restriction
>>> to support either type
>>> - IXmlConstraintParsers (legacy implementations) will continue to
>>> function, supporting only IXmlConstraintDescriptors
>>> - IConstraintParsers support any constraint-provider implementation
>>> that
>>> can supply it the parameters that it needs.
>>
>> May be, I have not state it clearly, but it solves only part of the
>> problem. A problem still remains in the case I want to implement a
>> provider which provides not only the constraints parsed by the new parser
>> interface but also the constraints parsed by the legacy parsers.
>> I think, it would be great if the constraint provider could load all the
>> supported
>> constraints, but let's say, just from a different storage.
>
> I think that this is something that your provider would have to do. Your
> constraint provider is responsible for creating constraints by asking the
> ConstraintFactory to parse IXmlConstraintDescriptors. Under the changes
> that I outlined, above, this would still be the case (only that the
> constraint descriptor would be a more general type). If you want to
> access
> legacy constraint languages, you would have to provide
> IXmlConstraintDescriptors.
>
> The problem with this, though, is that you will have to supply an
> implementation of IConfigurationElement to the descriptors, for the
> IXmlConstraintParsers to read their input in this form. This is an
> Eclipse
> API that you probably don't want to implement, because clients are not
> supposed to implement it (and it changes with every new OSGi update).
>
>
> <snip>
>
>> I think, that selecting live/batch constraints from those loaded by a
>> provider
>> and using a constraint Proxy for lazy initialization of the actual
>> implementation
>> might be a common functionality.
>> What seems to me specific is how constraint descriptors are loaded.
>> Could you please take a look at the patch attached to this post?
>> I have not created any bugzilla as I have a feeling I have not convinced
>> you
>> :)
>
> That's a good point. This patch looks OK, too, though you'll have to
> raise
> a new enhancement request and attach it, as you say. It's just a pulling
> up of existing functionality into the existing abstract provider.
>
> Thanks for doing all of this leg-work!
>
> Cheers,
>
> Christian
|
|
|
Re: [emf.validation.ocl] Custom EnvironmentFactory for OCL constraints [message #62881 is a reply to message #62610] |
Tue, 28 November 2006 19:19 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Radek,
I've attached a new patch to that enhancement you raised. Would you mind
trying it out to see whether it meets your requirements? It includes also
the patch that you provided for refactoring the OCL constraint
implementation, because I updated the OCLConstraintParser to support a new
constraint-parser API (which is the focus of the new patch).
Thanks for your help on this,
Christian
Radek Dvorak wrote:
> Hi Christian,
>
> Thanks, I have raised the enhancement
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=165661
>
> You are right, I would like to avoid implemeting IConfigurationElement.
> Not sure if it's feasible, but would be great, if there is a contract that
> the IXmlConstraintParser is considered a legacy interface and all newly
> introduced
> constraint-languages would be pluged-in using the new IConstraintParser.
>
> If yes, I would implement the new IConstraintParser for the few currently
> available languages
> rather then IConfigurationElement. AFAIU, ConstraintFactory would then
> provide a way
> to use also IConstraintParsers.
>
> Personally, I have a feeling that if the general IConstraintDescriptor
> interface also provided
>
> String getParameterValue(String name); // the parser specific params
> String getJavaClass();
>
> , there would be no reason to have IXmlConstraintDescriptor but only
> XmlConstraintDescriptor(impl of IConstraintDescriptor), which would just
> use the data parsed from plugin.xml.
> All other non-Xml... providers could use their own IConstraintDescriptor
> impl
> and parsers might have no dependency to IXmlConstraintDescriptor.
>
> I just wonder, if there is something I could have overlooked.
> Clearly, I am aware it is an API change, but I also think it could be
> solved without breaking
> the API contract for the current clients.
> If this is of low priority and no special effort is worth it, I would be
> more then willing to contribute
> a patch ;-).
>
> Regards,
> /Radek
>
>
<snip>
|
|
|
Re: [emf.validation.ocl] Custom EnvironmentFactory for OCL constraints [message #63295 is a reply to message #62881] |
Wed, 29 November 2006 17:57 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Radomil Dvorak![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=dvorak.radek%40gmail.com) Messages: 249 Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Looks like these are the changes I dreamed of ;-)
Thanks a lot.
Regards,
/Radek
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:eki24h$qsj$1@utils.eclipse.org...
>
> Hi, Radek,
>
> I've attached a new patch to that enhancement you raised. Would you mind
> trying it out to see whether it meets your requirements? It includes also
> the patch that you provided for refactoring the OCL constraint
> implementation, because I updated the OCLConstraintParser to support a ne
> constraint-parser API (which is the focus of the new patch).
>
> Thanks for your help on this,
>
> Christian
>
>
> Radek Dvorak wrote:
>
>> Hi Christian,
>>
>> Thanks, I have raised the enhancement
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=165661
>>
>> You are right, I would like to avoid implemeting IConfigurationElement.
>> Not sure if it's feasible, but would be great, if there is a contract
>> that
>> the IXmlConstraintParser is considered a legacy interface and all newly
>> introduced
>> constraint-languages would be pluged-in using the new IConstraintParser.
>>
>> If yes, I would implement the new IConstraintParser for the few currently
>> available languages
>> rather then IConfigurationElement. AFAIU, ConstraintFactory would then
>> provide a way
>> to use also IConstraintParsers.
>>
>> Personally, I have a feeling that if the general IConstraintDescriptor
>> interface also provided
>>
>> String getParameterValue(String name); // the parser specific params
>> String getJavaClass();
>>
>> , there would be no reason to have IXmlConstraintDescriptor but only
>> XmlConstraintDescriptor(impl of IConstraintDescriptor), which would just
>> use the data parsed from plugin.xml.
>> All other non-Xml... providers could use their own IConstraintDescriptor
>> impl
>> and parsers might have no dependency to IXmlConstraintDescriptor.
>>
>> I just wonder, if there is something I could have overlooked.
>> Clearly, I am aware it is an API change, but I also think it could be
>> solved without breaking
>> the API contract for the current clients.
>> If this is of low priority and no special effort is worth it, I would be
>> more then willing to contribute
>> a patch ;-).
>>
>> Regards,
>> /Radek
>>
>>
>
> <snip>
|
|
| |
Re: [emf.validation.ocl] Custom EnvironmentFactory for OCL constraints [message #596026 is a reply to message #62405] |
Mon, 20 November 2006 23:47 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Radek,
Unfortunately, this would mean specifying a lot of <parameter> elements in
the plugin.xml, always with the same value. How about defining your own
'constraint language' on the org.eclipse.emf.validation.constraintParsers
extension point, that uses a more appropriate language?
Also, as the number of constraints to be provided grows, the plugin.xml will
become difficult to manage. You may even want to consider implementing a
more efficient format for defining the constraints and registering a
dynamic constraint provider that makes them available at run-time, without
all of the messy plugin.xml.
Cheers,
Christian
Radek Dvorak wrote:
> Hi,
>
> Currrently, OCL constraints defined by using
> 'org.eclipse.emf.validation.constraintProviders' extension point
> use the default EnvironmentFactory.ECORE_INSTANCE.
>
> Could there be a support for providing a custom EnvironmentFactory to be
> used for OCL constraints defined by this
> extension point?
> I have noticed that the constraint definition may contain a <parameter>
> element, which can hold additional
> constraint-language-specific meta-data. Perhaps, this could be a way how
> to identify the EnvironmentFactory.
>
> Regards,
> /Radek
|
|
|
Re: [emf.validation.ocl] Custom EnvironmentFactory for OCL constraints [message #596034 is a reply to message #62431] |
Tue, 21 November 2006 17:04 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Radomil Dvorak![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=dvorak.radek%40gmail.com) Messages: 249 Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Thanks, for the response.
Ok, doing it by using the parser is fine.
Initiallly, I was thinking about a special constraint-language and its
parser.
I just did not like to duplicate quite some code doing nearly the same but
with a different env. factory. :)
But no code for reuse, everything internal. Something like public
(AbstractOCLModelConstraint base + abstract EnvironmentFactory
createEnvFactory())
might be helpful.
That's why I rather found that as something parameterizable.
What I find more troublesome is providing a custom dynamic constraint
provider, which I wanted to
to use to load constraints from an ecore model instance.
The reason is that all the currently supported parsers rely on
IXmlConstraintDescriptor which makes their
reuse with other providers impossible. This way, the parsers depend on the
type of persistence
chosen by a concrete provider.
Also, it seems to me that the XmlConstraintProvider class contains some of
the generic functionality which could be useful in
the AbstractConstraintProvider class to reduce the effort in implementing
specific providers.
Sorry for my laziness, which drives me to look for the easiest way to do
things :)
Or perhaps, I have not fully understand everything.
Regards,
/Radek
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:ejter0$sq9$1@utils.eclipse.org...
>
> Hi, Radek,
>
> Unfortunately, this would mean specifying a lot of <parameter> elements in
> the plugin.xml, always with the same value. How about defining your own
> 'constraint language' on the org.eclipse.emf.validation.constraintParsers
> extension point, that uses a more appropriate language?
>
> Also, as the number of constraints to be provided grows, the plugin.xml
> will
> become difficult to manage. You may even want to consider implementing a
> more efficient format for defining the constraints and registering a
> dynamic constraint provider that makes them available at run-time, without
> all of the messy plugin.xml.
>
> Cheers,
>
> Christian
>
>
> Radek Dvorak wrote:
>
>> Hi,
>>
>> Currrently, OCL constraints defined by using
>> 'org.eclipse.emf.validation.constraintProviders' extension point
>> use the default EnvironmentFactory.ECORE_INSTANCE.
>>
>> Could there be a support for providing a custom EnvironmentFactory to be
>> used for OCL constraints defined by this
>> extension point?
>> I have noticed that the constraint definition may contain a <parameter>
>> element, which can hold additional
>> constraint-language-specific meta-data. Perhaps, this could be a way how
>> to identify the EnvironmentFactory.
>>
>> Regards,
>> /Radek
>
|
|
|
Re: [emf.validation.ocl] Custom EnvironmentFactory for OCL constraints [message #596042 is a reply to message #62455] |
Tue, 21 November 2006 23:45 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Radek,
Don't worry about laziness. I think what you'relooking for is an API that's
easy to use! :-)
See some reponses in-line, below.
Cheers,
Christian
Radek Dvorak wrote:
> Hi Christian,
>
> Thanks, for the response.
> Ok, doing it by using the parser is fine.
>
> Initiallly, I was thinking about a special constraint-language and its
> parser.
> I just did not like to duplicate quite some code doing nearly the same but
> with a different env. factory. :)
> But no code for reuse, everything internal. Something like public
> (AbstractOCLModelConstraint base + abstract EnvironmentFactory
> createEnvFactory())
> might be helpful.
> That's why I rather found that as something parameterizable.
I'm not sure that one should really want to re-use the current
implementation of the oee.validation.ocl plug-in. :-) It's still using
some of the oldest and least friendly of the OCL parsing APIs, and it is so
small that cleaning it up and factoring out an API would hardly be worth
the effort. If you'd like, you can raise an enhancement request, and we'll
see what can be done. I would like to clean it up a bit if the
opportunity, but I don't know about adding any API. Of course, if you'd
like to contribute a patch ...
>
> What I find more troublesome is providing a custom dynamic constraint
> provider, which I wanted to
> to use to load constraints from an ecore model instance.
> The reason is that all the currently supported parsers rely on
> IXmlConstraintDescriptor which makes their
> reuse with other providers impossible. This way, the parsers depend on the
> type of persistence
> chosen by a concrete provider.
Quite right. What might be needed is something like:
- a new IConstraintParser interface with a that accepts an
IConstraintDescriptor and a Map of parameters (name/value pairs).
- relaxation of the constraintParsers extension point's type restriction
to support either type
- IXmlConstraintParsers (legacy implementations) will continue to
function, supporting only IXmlConstraintDescriptors
- IConstraintParsers support any constraint-provider implementation that
can supply it the parameters that it needs.
That's just what occurs to me on the spur of the moment. Would you mind
raising a bugzilla? I think this would be a bug, not an enhancement (it's
a design flaw). I believe that with this problem resolved, a custom
constraint language ("GMF-OCL"?) and custom constraint provider will be the
best solution for you.
> Also, it seems to me that the XmlConstraintProvider class contains some of
> the generic functionality which could be useful in
> the AbstractConstraintProvider class to reduce the effort in implementing
> specific providers.
I'm not sure that there's much in here to re-use. It's mostly about loading
constraints from IConfigurationElements ...
>
> Sorry for my laziness, which drives me to look for the easiest way to do
> things :)
> Or perhaps, I have not fully understand everything.
>
> Regards,
> /Radek
>
<snip>
|
|
|
Re: [emf.validation.ocl] Custom EnvironmentFactory for OCL constraints [message #596058 is a reply to message #62479] |
Wed, 22 November 2006 16:00 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Radomil Dvorak![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=dvorak.radek%40gmail.com) Messages: 249 Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
I have inserted yet another level of in-line comments. (hopefully can be
parsed...)
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:ek032r$o2d$1@utils.eclipse.org...
>
> Hi, Radek,
>
> Don't worry about laziness. I think what you'relooking for is an API
> that's
> easy to use! :-)
>
> See some reponses in-line, below.
>
> Cheers,
>
> Christian
>
>
> Radek Dvorak wrote:
>
>> Hi Christian,
>>
>> Thanks, for the response.
>> Ok, doing it by using the parser is fine.
>>
>> Initiallly, I was thinking about a special constraint-language and its
>> parser.
>> I just did not like to duplicate quite some code doing nearly the same
>> but
>> with a different env. factory. :)
>> But no code for reuse, everything internal. Something like public
>> (AbstractOCLModelConstraint base + abstract EnvironmentFactory
>> createEnvFactory())
>> might be helpful.
>> That's why I rather found that as something parameterizable.
>
> I'm not sure that one should really want to re-use the current
> implementation of the oee.validation.ocl plug-in. :-) It's still using
> some of the oldest and least friendly of the OCL parsing APIs, and it is
> so
> small that cleaning it up and factoring out an API would hardly be worth
> the effort. If you'd like, you can raise an enhancement request, and
> we'll
> see what can be done. I would like to clean it up a bit if the
> opportunity, but I don't know about adding any API. Of course, if you'd
> like to contribute a patch ...
True, not much to re-use in terms of the number of lines, but provided that
implementing
OCLModelConstraint + parser for every new flavor of OCL is the only way
how to support custom EnvironmentFactory, it would be nice if takes just a
few lines of coding. :)
Could you please review the patch at :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=165458 ?
I believe, at least OCL parsing, caching + the life-cycle management of the
parsed OCL AST
could be re-used. Not much, but boring to repeat :)
>>
>> What I find more troublesome is providing a custom dynamic constraint
>> provider, which I wanted to
>> to use to load constraints from an ecore model instance.
>> The reason is that all the currently supported parsers rely on
>> IXmlConstraintDescriptor which makes their
>> reuse with other providers impossible. This way, the parsers depend on
>> the
>> type of persistence
>> chosen by a concrete provider.
>
> Quite right. What might be needed is something like:
>
> - a new IConstraintParser interface with a that accepts an
> IConstraintDescriptor and a Map of parameters (name/value pairs).
> - relaxation of the constraintParsers extension point's type restriction
> to support either type
> - IXmlConstraintParsers (legacy implementations) will continue to
> function, supporting only IXmlConstraintDescriptors
> - IConstraintParsers support any constraint-provider implementation that
> can supply it the parameters that it needs.
May be, I have not state it clearly, but it solves only part of the problem.
A problem still remains in the case I want to implement a provider which
provides not only the constraints parsed by the new parser interface
but also the constraints parsed by the legacy parsers.
I think, it would be great if the constraint provider could load all the
supported
constraints, but let's say, just from a different storage.
I have raised a bugzilla:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=165455
> That's just what occurs to me on the spur of the moment. Would you mind
> raising a bugzilla? I think this would be a bug, not an enhancement (it's
> a design flaw). I believe that with this problem resolved, a custom
> constraint language ("GMF-OCL"?) and custom constraint provider will be
> the
> best solution for you.
>
>> Also, it seems to me that the XmlConstraintProvider class contains some
>> of
>> the generic functionality which could be useful in
>> the AbstractConstraintProvider class to reduce the effort in implementing
>> specific providers.
>
> I'm not sure that there's much in here to re-use. It's mostly about
> loading
> constraints from IConfigurationElements ...
I think, that selecting live/batch constraints from those loaded by a
provider
and using a constraint Proxy for lazy initialization of the actual
implementation
might be a common functionality.
What seems to me specific is how constraint descriptors are loaded.
Could you please take a look at the patch attached to this post?
I have not created any bugzilla as I have a feeling I have not convinced you
:)
>>
>> Sorry for my laziness, which drives me to look for the easiest way to do
>> things :)
>> Or perhaps, I have not fully understand everything.
>>
>> Regards,
>> /Radek
>>
>
> <snip>
|
|
|
Re: [emf.validation.ocl] Custom EnvironmentFactory for OCL constraints [message #596068 is a reply to message #62524] |
Wed, 22 November 2006 23:42 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Radek,
I have severely edited the text, this time. ;-)
Radek Dvorak wrote:
<snip>
> True, not much to re-use in terms of the number of lines, but provided
> that implementing
> OCLModelConstraint + parser for every new flavor of OCL is the only way
> how to support custom EnvironmentFactory, it would be nice if takes just a
> few lines of coding. :)
> Could you please review the patch at :
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=165458 ?
> I believe, at least OCL parsing, caching + the life-cycle management of
> the parsed OCL AST
> could be re-used. Not much, but boring to repeat :)
True enough! The patch that you attached looks good to me.
<snip>
>> Quite right. What might be needed is something like:
>>
>> - a new IConstraintParser interface with a that accepts an
>> IConstraintDescriptor and a Map of parameters (name/value pairs).
>> - relaxation of the constraintParsers extension point's type restriction
>> to support either type
>> - IXmlConstraintParsers (legacy implementations) will continue to
>> function, supporting only IXmlConstraintDescriptors
>> - IConstraintParsers support any constraint-provider implementation that
>> can supply it the parameters that it needs.
>
> May be, I have not state it clearly, but it solves only part of the
> problem. A problem still remains in the case I want to implement a
> provider which provides not only the constraints parsed by the new parser
> interface but also the constraints parsed by the legacy parsers.
> I think, it would be great if the constraint provider could load all the
> supported
> constraints, but let's say, just from a different storage.
I think that this is something that your provider would have to do. Your
constraint provider is responsible for creating constraints by asking the
ConstraintFactory to parse IXmlConstraintDescriptors. Under the changes
that I outlined, above, this would still be the case (only that the
constraint descriptor would be a more general type). If you want to access
legacy constraint languages, you would have to provide
IXmlConstraintDescriptors.
The problem with this, though, is that you will have to supply an
implementation of IConfigurationElement to the descriptors, for the
IXmlConstraintParsers to read their input in this form. This is an Eclipse
API that you probably don't want to implement, because clients are not
supposed to implement it (and it changes with every new OSGi update).
<snip>
> I think, that selecting live/batch constraints from those loaded by a
> provider
> and using a constraint Proxy for lazy initialization of the actual
> implementation
> might be a common functionality.
> What seems to me specific is how constraint descriptors are loaded.
> Could you please take a look at the patch attached to this post?
> I have not created any bugzilla as I have a feeling I have not convinced
> you
> :)
That's a good point. This patch looks OK, too, though you'll have to raise
a new enhancement request and attach it, as you say. It's just a pulling
up of existing functionality into the existing abstract provider.
Thanks for doing all of this leg-work!
Cheers,
Christian
|
|
|
Re: [emf.validation.ocl] Custom EnvironmentFactory for OCL constraints [message #596107 is a reply to message #62539] |
Thu, 23 November 2006 17:36 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Radomil Dvorak![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=dvorak.radek%40gmail.com) Messages: 249 Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Thanks, I have raised the enhancement
https://bugs.eclipse.org/bugs/show_bug.cgi?id=165661
You are right, I would like to avoid implemeting IConfigurationElement.
Not sure if it's feasible, but would be great, if there is a contract that
the IXmlConstraintParser is considered a legacy interface and all newly
introduced
constraint-languages would be pluged-in using the new IConstraintParser.
If yes, I would implement the new IConstraintParser for the few currently
available languages
rather then IConfigurationElement. AFAIU, ConstraintFactory would then
provide a way
to use also IConstraintParsers.
Personally, I have a feeling that if the general IConstraintDescriptor
interface also provided
String getParameterValue(String name); // the parser specific params
String getJavaClass();
, there would be no reason to have IXmlConstraintDescriptor but only
XmlConstraintDescriptor(impl of IConstraintDescriptor), which would just use
the data parsed from plugin.xml.
All other non-Xml... providers could use their own IConstraintDescriptor
impl
and parsers might have no dependency to IXmlConstraintDescriptor.
I just wonder, if there is something I could have overlooked.
Clearly, I am aware it is an API change, but I also think it could be solved
without breaking
the API contract for the current clients.
If this is of low priority and no special effort is worth it, I would be
more then willing to contribute
a patch ;-).
Regards,
/Radek
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:ek2n9f$j8p$1@utils.eclipse.org...
> Hi, Radek,
>
> I have severely edited the text, this time. ;-)
>
>
>
> Radek Dvorak wrote:
>
> <snip>
>
>> True, not much to re-use in terms of the number of lines, but provided
>> that implementing
>> OCLModelConstraint + parser for every new flavor of OCL is the only way
>> how to support custom EnvironmentFactory, it would be nice if takes just
>> a
>> few lines of coding. :)
>> Could you please review the patch at :
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=165458 ?
>> I believe, at least OCL parsing, caching + the life-cycle management of
>> the parsed OCL AST
>> could be re-used. Not much, but boring to repeat :)
>
> True enough! The patch that you attached looks good to me.
>
>
> <snip>
>
>>> Quite right. What might be needed is something like:
>>>
>>> - a new IConstraintParser interface with a that accepts an
>>> IConstraintDescriptor and a Map of parameters (name/value pairs).
>>> - relaxation of the constraintParsers extension point's type
>>> restriction
>>> to support either type
>>> - IXmlConstraintParsers (legacy implementations) will continue to
>>> function, supporting only IXmlConstraintDescriptors
>>> - IConstraintParsers support any constraint-provider implementation
>>> that
>>> can supply it the parameters that it needs.
>>
>> May be, I have not state it clearly, but it solves only part of the
>> problem. A problem still remains in the case I want to implement a
>> provider which provides not only the constraints parsed by the new parser
>> interface but also the constraints parsed by the legacy parsers.
>> I think, it would be great if the constraint provider could load all the
>> supported
>> constraints, but let's say, just from a different storage.
>
> I think that this is something that your provider would have to do. Your
> constraint provider is responsible for creating constraints by asking the
> ConstraintFactory to parse IXmlConstraintDescriptors. Under the changes
> that I outlined, above, this would still be the case (only that the
> constraint descriptor would be a more general type). If you want to
> access
> legacy constraint languages, you would have to provide
> IXmlConstraintDescriptors.
>
> The problem with this, though, is that you will have to supply an
> implementation of IConfigurationElement to the descriptors, for the
> IXmlConstraintParsers to read their input in this form. This is an
> Eclipse
> API that you probably don't want to implement, because clients are not
> supposed to implement it (and it changes with every new OSGi update).
>
>
> <snip>
>
>> I think, that selecting live/batch constraints from those loaded by a
>> provider
>> and using a constraint Proxy for lazy initialization of the actual
>> implementation
>> might be a common functionality.
>> What seems to me specific is how constraint descriptors are loaded.
>> Could you please take a look at the patch attached to this post?
>> I have not created any bugzilla as I have a feeling I have not convinced
>> you
>> :)
>
> That's a good point. This patch looks OK, too, though you'll have to
> raise
> a new enhancement request and attach it, as you say. It's just a pulling
> up of existing functionality into the existing abstract provider.
>
> Thanks for doing all of this leg-work!
>
> Cheers,
>
> Christian
|
|
|
Re: [emf.validation.ocl] Custom EnvironmentFactory for OCL constraints [message #596268 is a reply to message #62610] |
Tue, 28 November 2006 19:19 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Radek,
I've attached a new patch to that enhancement you raised. Would you mind
trying it out to see whether it meets your requirements? It includes also
the patch that you provided for refactoring the OCL constraint
implementation, because I updated the OCLConstraintParser to support a new
constraint-parser API (which is the focus of the new patch).
Thanks for your help on this,
Christian
Radek Dvorak wrote:
> Hi Christian,
>
> Thanks, I have raised the enhancement
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=165661
>
> You are right, I would like to avoid implemeting IConfigurationElement.
> Not sure if it's feasible, but would be great, if there is a contract that
> the IXmlConstraintParser is considered a legacy interface and all newly
> introduced
> constraint-languages would be pluged-in using the new IConstraintParser.
>
> If yes, I would implement the new IConstraintParser for the few currently
> available languages
> rather then IConfigurationElement. AFAIU, ConstraintFactory would then
> provide a way
> to use also IConstraintParsers.
>
> Personally, I have a feeling that if the general IConstraintDescriptor
> interface also provided
>
> String getParameterValue(String name); // the parser specific params
> String getJavaClass();
>
> , there would be no reason to have IXmlConstraintDescriptor but only
> XmlConstraintDescriptor(impl of IConstraintDescriptor), which would just
> use the data parsed from plugin.xml.
> All other non-Xml... providers could use their own IConstraintDescriptor
> impl
> and parsers might have no dependency to IXmlConstraintDescriptor.
>
> I just wonder, if there is something I could have overlooked.
> Clearly, I am aware it is an API change, but I also think it could be
> solved without breaking
> the API contract for the current clients.
> If this is of low priority and no special effort is worth it, I would be
> more then willing to contribute
> a patch ;-).
>
> Regards,
> /Radek
>
>
<snip>
|
|
|
Re: [emf.validation.ocl] Custom EnvironmentFactory for OCL constraints [message #596349 is a reply to message #62881] |
Wed, 29 November 2006 17:57 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Radomil Dvorak![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=dvorak.radek%40gmail.com) Messages: 249 Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Looks like these are the changes I dreamed of ;-)
Thanks a lot.
Regards,
/Radek
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:eki24h$qsj$1@utils.eclipse.org...
>
> Hi, Radek,
>
> I've attached a new patch to that enhancement you raised. Would you mind
> trying it out to see whether it meets your requirements? It includes also
> the patch that you provided for refactoring the OCL constraint
> implementation, because I updated the OCLConstraintParser to support a ne
> constraint-parser API (which is the focus of the new patch).
>
> Thanks for your help on this,
>
> Christian
>
>
> Radek Dvorak wrote:
>
>> Hi Christian,
>>
>> Thanks, I have raised the enhancement
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=165661
>>
>> You are right, I would like to avoid implemeting IConfigurationElement.
>> Not sure if it's feasible, but would be great, if there is a contract
>> that
>> the IXmlConstraintParser is considered a legacy interface and all newly
>> introduced
>> constraint-languages would be pluged-in using the new IConstraintParser.
>>
>> If yes, I would implement the new IConstraintParser for the few currently
>> available languages
>> rather then IConfigurationElement. AFAIU, ConstraintFactory would then
>> provide a way
>> to use also IConstraintParsers.
>>
>> Personally, I have a feeling that if the general IConstraintDescriptor
>> interface also provided
>>
>> String getParameterValue(String name); // the parser specific params
>> String getJavaClass();
>>
>> , there would be no reason to have IXmlConstraintDescriptor but only
>> XmlConstraintDescriptor(impl of IConstraintDescriptor), which would just
>> use the data parsed from plugin.xml.
>> All other non-Xml... providers could use their own IConstraintDescriptor
>> impl
>> and parsers might have no dependency to IXmlConstraintDescriptor.
>>
>> I just wonder, if there is something I could have overlooked.
>> Clearly, I am aware it is an API change, but I also think it could be
>> solved without breaking
>> the API contract for the current clients.
>> If this is of low priority and no special effort is worth it, I would be
>> more then willing to contribute
>> a patch ;-).
>>
>> Regards,
>> /Radek
>>
>>
>
> <snip>
|
|
| |
Goto Forum:
Current Time: Sun Aug 18 09:26:38 GMT 2024
Powered by FUDForum. Page generated in 0.05946 seconds
|