12 Apr
2005
12 Apr
'05
11:39 p.m.
Hi David,
There's probably a bug in
SW2PluggableComponent>>renderContentOn:
This class has a block as an inst var and in #renderContentOn: this
block is
analyzed if it expects two args. If not, it's tried to render this
block
with html render: block. But this won't work, because a block can't be
rendered directly.
well what do you do with your all your div, span, heading and
anchor-tags? There are blocks that are rendered all over the place :-)
html div: [
html span: [
html heading: [
html
anchorWith...
do: [ ... ] ] ] ].
Have a look at WAAbstractHtmlBuilder>>render: and
BlockContext>>renderOn: where the double dispatch on blocks happens. As
you can see Seaside accepts zero and one argument blocks, and I
enhanced this for SW2PluggableComponent to have two possible arguments.
However it is generally not a very good idea to use
SW2PluggableComponent extensively, but for fast prototyping its use
might be nice. Currently there is no use of SW2PluggableComponent in
SmallWiki2 anymore.
Another issue is that the style-sheet is stored in a
remote file which
we
could not change/extend. Wouldn't it be better to have the style
definitions
directly in the image? For instance you could create a style library
class
for SW2.
Please submit a patch to SmallWiki2-Seaside, I just didn't bothered to
put all those style-sheets and images into a style library class yet,
it was simply easier for me to edit the file in a css-editor. Check out
the new style, it has some fancy css-buttons in the heading-bar!
Then I have encountered a problem with the commands
for a structure. I
have
created a new subclass of Structure and now I would like to define some
commands for this new kind of structure. But then all the other
commands
that are bound to Structure (like Move, Copy, Add, ...) will also be
displayed in the command widget when browsing an instance of this new
structure. I see no way to specify that these commands should not be
available for my newly defined structure. It would be better to have
the
possibility to explicitly say for which structures a command should be
available. A collection of structure classes instead of SW2Command
class >>
defaultStructureClass maybe?
I see the problem, but having collection the commands (static state)
wouldn't solve the problem either, because one cannot know what
structure and commands (it is an m to n relationship) will exist in the
future. It also gets difficult because one doesn't know who has the
responsibility to register the commands, the command or the structure?
Generally I prefer dynamic state, that means we should introduce
another dispatch in SW2Context>>allValidCommands to let the command and
the structure have the possibility to reject a command.
Another problem with newly created subclasses of
Structure is that
they will
all appear in the 'type'-dropdown when adding a child structure with
the
AddCommand. This might not be desired for all subclasses of Structure.
Similar problem as above: I suggest that you submit a patch to the
latest SmallWiki2 package that fits your needs so that it can be merged
into the core code and everybody can profit.
It would be great to have a method
MAElementDescription >>
attributeAt:put:
to specify new attributes for the component of a description.
Currently, one
has to use #attributes which is not convenient.
Margritte is not a Seaside framework, generally speaking.
As far as I know there is just one use of #attributes: in SmallWiki
itself and as I don't write code that I don't need, I didn't felt the
need for such methods yet. However feel free to add them for your
convenience, that's the reason why there are class extensions ;-)
Then there are several components available that
render a text field
with a
button, such as MADateInputComponent, MATimestampInputComponent, ... I
tried
to create a subclass of such a component to change the button's
appearance
(different label or an image as button). But this is not possible
because
the button is rendered directly in #renderEditorOn:, so I can't
override
this method. It would be better to have a method #renderButtonOn: in
MATextInputComponent, so all subclasses with a button have to override
just
this method which would be empty in MATextInputComponent.
Yeah, I see, maybe sometimes I am too lazy.
But besides that, Magritte is really cool. :)
Thanks.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
13 Apr
13 Apr
1:10 p.m.
New subject: Some problems with SW2
Hello Lukas,
hm, yes, but I think this might be a feature of general interest, because
the possibility to adapt the components when defining the description could
be important for many forms that will be created with Magritte in the
future. Otherwise, all the form elements are bound to have the same look
(width, height, alignment, etc.), and for forms that are a bit more complex,
e.g., with different text areas for different types of content, it might be
useful to adapt the look of the different form elements according to what
they represent.
I have developed a similar framework (in PHP, don't laugh ;) in the past,
and there the ability to customize the different form elements freely is
really crucial because we have to create many different and complex forms
with it.
Or how do you see the future of Magritte? I think it has a great potential
and the possibility to customize the components easily without subclassing
might come in quite handy.
Another issue currently is the customization of a description if it depends
on the instance of the structure. For instance, one would like to have
elements in a select list that are dependent on the instance of a structure
and that cannot be determined statically. As far as I understand the only
possibility to achieve that is to override #description on the
instance-side and to add the desired instance-dependent elements there. Or
am I mistaken here?
David
well what do you do with your all your div, span,
heading and anchor-tags?
There are blocks that are rendered all over the place :-)
yep, sorry, my bad, I have made a mess. ;)
Please submit a patch to SmallWiki2-Seaside, I just
didn't bothered to put
all those style-sheets and images into a style library class yet, it was
simply easier for me to edit the file in a css-editor.
yes, I see. I can add the styles to a library, no problem.
Similar problem as above: I suggest that you submit a
patch to the latest
SmallWiki2 package that fits your needs so that it can be merged into the
core code and everybody can profit.
ok, I can try.
It would be
great to have a method MAElementDescription >>
attributeAt:put:
to specify new attributes for the component of a description. Currently,
one
has to use #attributes which is not convenient.
Margritte is not a Seaside framework, generally speaking.
As far as I know there is just one use of #attributes: in SmallWiki itself
and as I don't write code that I don't need, I didn't felt the need for
such methods yet. However feel free to add them for your convenience,
that's the reason why there are class extensions ;-)
7:33 p.m.
New subject: Some problems with SW2
It would be great to have a method
MAElementDescription >>
attributeAt:put:
to specify new attributes for the component of a description.
Currently,
one
has to use #attributes which is not convenient.
Margritte is not a Seaside framework, generally speaking.
As far as I know there is just one use of #attributes: in SmallWiki
itself
and as I don't write code that I don't need, I didn't felt the need
for
such methods yet. However feel free to add them for your convenience,
that's the reason why there are class extensions ;-) Or how do you see the future of Magritte? I think it
has a great
potential and the possibility to customize the components easily
without subclassing might come in quite handy.
As I mentioned in the presentation, we are using Magritte in industrial
environment as well, where the users are able to click together
web-forms on their own and specify arbitrary complex validation rules.
Another issue currently is the customization of a
description if it
depends
on the instance of the structure. For instance, one would like to have
elements in a select list that are dependent on the instance of a
structure
and that cannot be determined statically. As far as I understand the
only
possibility to achieve that is to override #description on the
instance-side and to add the desired instance-dependent elements
there. Or
am I mistaken here?
Yes, you are! You can do it on the class side using the
description-builder as well. Imagine a hierarchy where A is the
superclass of B and B is the superclass of C:
A class>>descriptionFoo
^(MAOptionsDescrion key: #foo)
options: self optionsToBeUsed;
yourself.
A class>>optionsToBeUsed
^#( a b c )
B class>>optionsToBeUsed
^super optionsToBeUsed , #( 1 2 )
A will have description with #( a b c ), whereas B will have one with
#( a b c 1 2 ).
Another powerful thing is the MADynamicObject class, that allows to
define descriptions where you don't know the possible properties in
advance. Try something like:
B class>>optionsToBeUsed
^MADynamicObject on: [ 1 to: 100 atRandom ].
It is also possible to clear a description element in a subclass, by
overriding the description method and returning nil
C class>>descriptionFoo
^nil
or you could change the description of the superclass by modifying it:
C class>>descriptionFoo
^super descriptionFoo
beReadonly;
nilLabel: 'nothing';
yourself.
Och, I like objects so much ;-)
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
14 Apr
14 Apr
9:38 p.m.
New subject: AW: Some problems with SW2
Hi Lukas,
> Another issue currently is the customization of a
description if it
> depends on the instance of the structure. For instance, one would like
> to have elements in a select list that are dependent on the instance
> of a structure and that cannot be determined statically. As far as I
> understand the only possibility to achieve that is to override
> #description on the instance-side and to add the desired
> instance-dependent elements there. Or am I mistaken here?
Another powerful thing is the MADynamicObject class,
that
allows to define descriptions where you don't know the
possible properties in advance. Try something like:
B class>>optionsToBeUsed
^MADynamicObject on: [ 1 to: 100 atRandom ].
Sorry, I don't understand how this is then dependent on the instance,
because this is still on the class side, no?
I have checked MADynamicObject, but I don't see how can I bring in some
instance-based properties?
Maybe I did't clarify my problem well enough, so here's an example of what I
would like to do:
A >> elements
^Array with: instvar1 with: instvar2 with: instvar3
A class >> descriptionElements
^(MAOptionsDescription key: #foo)
options: (MADynamicObject on: [ "how can I get
access to A >> elements here?" ]);
yourself.
So I need a way to get the options from instances of the class in which I
define the description.
Maybe something like a block, such as MADynamicObject on: [:instance |
instance elements]. When the options component (select list, radio buttons,
...) is built up, the arg of the block should be bound to the concrete
instance of A and then the options are fetched from the #elements method of
this instance.
As I said, so far I add the options answered by #elements to the options
description in A >> description, an override of Object >> description.
It is also possible to clear a description element in
a
subclass, by overriding the description method and returning nil
C class>>descriptionFoo
^nil
or you could change the description of the superclass by modifying it:
C class>>descriptionFoo
^super descriptionFoo
beReadonly;
nilLabel: 'nothing';
yourself.
Yep, I have seen that, indeed very useful.
David
7192
days inactive
7194
days old
3 comments
2 participants
participants (2)
-
David Röthlisberger -
Lukas Renggli