19 Feb
2010
19 Feb
'10
4:03 p.m.
In the MARelationDescription it is possible to specify a variety of target clases that can
be used. If I have more than one I cannot set the reference at the same time. This gives
me trouble using MAExternalEditorComponent.
Shouldn't
MARelationComponent>>editorFor: anObject
^ (self description reference asComponentOn: anObject)
addValidatedForm;
yourself
be rather
MARelationComponent>>editorFor: anObject
^ (anObject description asComponentOn: anObject)
addValidatedForm;
yourself
?
Norbert
20 Feb
20 Feb
9:45 a.m.
Shouldn't
MARelationComponent>>editorFor: anObject
^ (self description reference asComponentOn: anObject)
addValidatedForm;
yourself
be rather
MARelationComponent>>editorFor: anObject
^ (anObject description asComponentOn: anObject)
addValidatedForm;
yourself
?
It depends what you want to do. I suggest that you create a subclass
that works for your use-case.
As I already explained here several times, I've personally never used
the relationships. I rarely found the default behavior useful, and
another default behavior was not useful in other contexts.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
3:20 p.m.
Hello Lukas,
On Sat, Feb 20, 2010 at 3:45 AM, Lukas Renggli <renggli(a)gmail.com> wrote:
I have always found this statement to be somewhat disturbing on each of
those several occasions.
Could you elaborate on this a little? What *would* you use to describe a
collection? Do you mean that you always subclass the needed relationship
classes to suit your needs?
Thanks
John
Shouldn't
MARelationComponent>>editorFor: anObject
^ (self description reference asComponentOn: anObject)
addValidatedForm;
yourself
be rather
MARelationComponent>>editorFor: anObject
^ (anObject description asComponentOn: anObject)
addValidatedForm;
yourself
?
It depends what you want to do. I suggest that you create a subclass
that works for your use-case.
As I already explained here several times, I've personally never used
the relationships. I rarely found the default behavior useful, and
another default behavior was not useful in other contexts.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
http://jmck.seasidehosting.st
7:27 p.m.
Lukas,
I must agree with John. I never understood your quick and anti-relationship responses. I
think it is an important part of the meta model that you can try to model a complex
scenario with relationships. I agree that it is difficult to find a default behaviour of
all those. I would like to hear your answers to Johns questions as well.
Just to repeat myself. You can specify a relationship to a variety of possible target
classes. I'm not sure what reference is meant for exaclty but I can't barely
imagine a case where the component to build is not dependent on the object being edited. I
would be glad to hear something that conflicts with this.
thanks,
Norbert
On 20.02.2010, at 15:20, John McKeon wrote:
Hello Lukas,
On Sat, Feb 20, 2010 at 3:45 AM, Lukas Renggli <renggli(a)gmail.com> wrote:
Shouldn't
MARelationComponent>>editorFor: anObject
^ (self description reference asComponentOn: anObject)
addValidatedForm;
yourself
be rather
MARelationComponent>>editorFor: anObject
^ (anObject description asComponentOn: anObject)
addValidatedForm;
yourself
?
It depends what you want to do. I suggest that you create a subclass
that works for your use-case.
As I already explained here several times, I've personally never used
the relationships. I rarely found the default behavior useful, and
another default behavior was not useful in other contexts.
I have always found this statement to be somewhat disturbing on each of those several
occasions.
Could you elaborate on this a little? What *would* you use to describe a collection? Do
you mean that you always subclass the needed relationship classes to suit your needs?
Thanks
John
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
http://jmck.seasidehosting.st
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
7:52 p.m.
I must agree with John. I never understood your quick
and anti-relationship
responses. I think it is an important part of the meta model that you can
try to model a complex scenario with relationships. I agree that it is
difficult to find a default behaviour of all those. I would like to hear
your answers to Johns questions as well.
The relationships work for simple things. In practice however I have
always felt the need to customize the descriptions through one or more
of the extension mechanisms in Magritte, either for usability or to
satisfy particular customer requests.
I must say that the current implementation is more at the state of a
proof of concept. I never used relationships in any project (other
than the Magritte meta editor in Magritte itself), it is largely
untested in practice. The only changes relationships have seen since
my Master in 2006 were fixes that other people have submitted. The
fact that some of these fixes got reverted again by newer fixes has
led me to the conclusion that at least in the current form the
implementation of relationships is fragile and I refrain from
suggesting its use.
I found it more flexible and user-friendly to let Magritte create
simple components only. I would then compose these individual
components in a master component. This allows one to easily create
arbitrary complex forms with custom navigation between different
objects that exactly match the wishes of the customer with relatively
little glue code.
I know that other web and meta-frameworks go much further here. I
would not mind somebody talking over the issue an implement (and
maintain) better working and well tested relationship descriptions
that solve the current problems.
Lukas
Just to repeat myself. You can specify a relationship
to a variety of
possible target classes. I'm not sure what reference is meant for exaclty
but I can't barely imagine a case where the component to build is not
dependent on the object being edited. I would be glad to hear something that
conflicts with this.
thanks,
Norbert
On 20.02.2010, at 15:20, John McKeon wrote:
Hello Lukas,
On Sat, Feb 20, 2010 at 3:45 AM, Lukas Renggli <renggli(a)gmail.com> wrote:
I have always found this statement to be somewhat disturbing on each of
those several occasions.
Could you elaborate on this a little? What *would* you use to describe a
collection? Do you mean that you always subclass the needed relationship
classes to suit your needs?
Thanks
John
--
Lukas Renggli
http://www.lukas-renggli.ch
Shouldn't
MARelationComponent>>editorFor: anObject
^ (self description reference asComponentOn: anObject)
addValidatedForm;
yourself
be rather
MARelationComponent>>editorFor: anObject
^ (anObject description asComponentOn: anObject)
addValidatedForm;
yourself
?
It depends what you want to do. I suggest that you create a subclass
that works for your use-case.
As I already explained here several times, I've personally never used
the relationships. I rarely found the default behavior useful, and
another default behavior was not useful in other contexts.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
http://jmck.seasidehosting.st
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
21 Feb
21 Feb
3:57 a.m.
On Sat, Feb 20, 2010 at 1:52 PM, Lukas Renggli <renggli(a)gmail.com> wrote:
Thank you for your reply Lukas. This is very illuminating. I have not
ventured much further than the typical "invoice/line item" type of
relationships so I have yet to run into any problems that cannot be overcome
by overriding and adding some special behavior. For now I find them quite
useful.
I am thinking over the last paragraph before committing to anything, though
it is an enticing offer. Does it pay well?
Thanks again
John
I have always found this statement to be somewhat disturbing on each of
those several occasions.
Could you elaborate on this a little? What *would* you use to describe a
collection? Do you mean that you always subclass the needed relationship
classes to suit your needs?
Thanks
John
--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
http://jmck.seasidehosting.st
I must agree
with John. I never understood your quick and
anti-relationship
responses. I think it is an important part of the
meta model that you can
try to model a complex scenario with relationships. I agree that it is
difficult to find a default behaviour of all those. I would like to hear
your answers to Johns questions as well.
The relationships work for simple things. In practice however I have
always felt the need to customize the descriptions through one or more
of the extension mechanisms in Magritte, either for usability or to
satisfy particular customer requests.
I must say that the current implementation is more at the state of a
proof of concept. I never used relationships in any project (other
than the Magritte meta editor in Magritte itself), it is largely
untested in practice. The only changes relationships have seen since
my Master in 2006 were fixes that other people have submitted. The
fact that some of these fixes got reverted again by newer fixes has
led me to the conclusion that at least in the current form the
implementation of relationships is fragile and I refrain from
suggesting its use.
I found it more flexible and user-friendly to let Magritte create
simple components only. I would then compose these individual
components in a master component. This allows one to easily create
arbitrary complex forms with custom navigation between different
objects that exactly match the wishes of the customer with relatively
little glue code.
I know that other web and meta-frameworks go much further here. I
would not mind somebody talking over the issue an implement (and
maintain) better working and well tested relationship descriptions
that solve the current problems.
Lukas
Just to repeat myself. You can specify a
relationship to a variety of
possible target classes. I'm not sure what reference is meant for exaclty
but I can't barely imagine a case where the component to build is not
dependent on the object being edited. I would be glad to hear something
that
conflicts with this.
thanks,
Norbert
On 20.02.2010, at 15:20, John McKeon wrote:
Hello Lukas,
On Sat, Feb 20, 2010 at 3:45 AM, Lukas Renggli <renggli(a)gmail.com>
wrote:
Shouldn't
MARelationComponent>>editorFor: anObject
^ (self description reference asComponentOn: anObject)
addValidatedForm;
yourself
be rather
MARelationComponent>>editorFor: anObject
^ (anObject description asComponentOn: anObject)
addValidatedForm;
yourself
?
It depends what you want to do. I suggest that you create a subclass
that works for your use-case.
As I already explained here several times, I've personally never used
the relationships. I rarely found the default behavior useful, and
another default behavior was not useful in other contexts.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
http://jmck.seasidehosting.st
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
5188
days inactive
5190
days old
5 comments
3 participants
participants (3)
-
John McKeon -
Lukas Renggli -
Norbert Hartl