19 Aug
2008
19 Aug
'08
8:40 a.m.
Lukas et-al,
I've got my test Magritte form working from a renderContentOn: block
without issue (data is displayed,buttons exist,no complaints, etc)..
Anyway, at the bottom of the form (using the code below) are 3 buttons
(save,cancel and then my 'done' button).. The thing I'm having a hard
time with (which was easy when using #call and #answer) is how to
determine what button was pressed (save,cancel).. Ideally, I don't
care to have a "done" button but I do need to distinguish between save
and cancel.. What's the best approach for this? I copied the
onAnswer: block from another old Magritte email thread but its only
called when cancel is pressed.. Thx!
renderContentOn: html
component := (self session user) asComponent addValidatedForm;
onAnswer: [ :value | self answer: value ];
yourself.
html div id: 'fullwidthContent'; with: [
html div id: #fieldsetEnclosure; with: [
html render: component.
html submitButton
callback: [self answer: 'foo'];
text: 'Done'
]
]
-- Rick
19 Aug
19 Aug
9:31 a.m.
and cancel.. What's the best approach for this? I
copied the
onAnswer: block from another old Magritte email thread but its only
called when cancel is pressed.. Thx!
The #onAnswer: trick is the right thing to do here.
renderContentOn: html
component := (self session user) asComponent addValidatedForm;
onAnswer: [ :value | self answer: value ];
yourself.
html div id: 'fullwidthContent'; with: [
html div id: #fieldsetEnclosure; with: [
html render: component.
html submitButton
callback: [self answer: 'foo'];
text: 'Done'
]
]
The problem is that, #asComponent will create a new component every
time the page is rendered. So you need to move the code
component := (self session user) asComponent
addValidatedForm;
onAnswer: [ :value | self answer: value ];
yourself.
to #initialize of the component and answer component from #children.
Another problem I see is the #submitButton, that is outside the form
that you added with #addValidatedForm. To get your 'done' button into
the form you might want to customize the decorator like:
... addValidatedForm: #( save cancel done )
Now you need to add #done as an extension method to
MAContainerComponent to #answer: something meaningful. It's not that
nice, but it works ;-)
Btw, #save answers the changed model and #cancel answers nil.
Hope this helps,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
2:12 p.m.
>>>> "Lukas" == Lukas Renggli
<renggli(a)iam.unibe.ch> writes:
Lukas> ... addValidatedForm: #( save cancel done )
Lukas> Now you need to add #done as an extension method to
Lukas> MAContainerComponent to #answer: something meaningful. It's not that
Lukas> nice, but it works ;-)
This is where I had wished that the form stuff would be pluggable instead of
only being able to be extended by subclassing. Did you consider a pluggable
strategy here, and rejected it for some other reason? The notion of
subclassing just to get a slight variation still tweaks me somehow. Maybe
it's just a quirk I need to get over... :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
4:29 p.m.
Lukas> ... addValidatedForm: #( save cancel done
)
Lukas> Now you need to add #done as an extension method to
Lukas> MAContainerComponent to #answer: something meaningful. It's
not that
Lukas> nice, but it works ;-)
This is where I had wished that the form stuff would be pluggable
instead of
only being able to be extended by subclassing.
I am not using subclassing. I am talking about pluggability through
method extensions ;-)
Did you consider a pluggable
strategy here, and rejected it for some other reason? The notion of
subclassing just to get a slight variation still tweaks me somehow.
Maybe
it's just a quirk I need to get over... :)
One of the design goals of Magritte was, not to have blocks
everywhere. I guess in this case that got a bit too far. It would make
sense to tell the decoration:
aFormDecoration
on: 'Done' do: [ :answer | self inform: 'done' ]
I will have a look later tonight if that could be done easily. Or
maybe you are faster to implement something like this?
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
4:45 p.m.
>>>> "Lukas" == Lukas Renggli
<renggli(a)iam.unibe.ch> writes:
Lukas> One of the design goals of Magritte was, not to have blocks
Lukas> everywhere. I guess in this case that got a bit too far. It would make
Lukas> sense to tell the decoration:
Lukas> aFormDecoration
Lukas> on: 'Done' do: [ :answer | self inform: 'done' ]
This looks great! Exactly what I had in mind.
Lukas> I will have a look later tonight if that could be done easily. Or
Lukas> maybe you are faster to implement something like this?
I won't get to it today, if that's what you're hoping. :) But I'll
be happy to use it once it comes out.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
11:04 p.m.
On Aug 19, 2008, at 16:45 , Randal L. Schwartz wrote:
In Magritte-Seaside.lr.273 you can write something like this (not that
I suggest that you should do it):
aModel asComponent
addValidatedForm: (Array
with: #save -> 'Yes'
with: [ :component |
component validate
ifFalse: [ component inform: 'There is a problem' ]
ifTrue: [
(component confirm: 'Save?')
ifTrue: [ component save ].
(component confirm: 'Answer?')
ifTrue: [ component answer: component
model ] ] ]
-> 'Maybe'
with: #cancel -> 'No');
yourself
I haven't tested it too much, at least it shouldn't break existing code.
There is obviously a culprit. When you use a block you have to do
everything by yourself. Validation, saving, reset, answering, etc. The
example above demonstrates pretty much everything you might want to do.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
>>>> "Lukas" == Lukas Renggli <renggli(a)iam.unibe.ch> writes:
Lukas> One of the design goals of Magritte was, not to have blocks
Lukas> everywhere. I guess in this case that got a bit too far. It
would make
Lukas> sense to tell the decoration:
Lukas> aFormDecoration
Lukas> on: 'Done' do: [ :answer | self inform: 'done' ]
This looks great! Exactly what I had in mind.
4:16 p.m.
On Aug 19, 2008, at 12:31 AM, Lukas Renggli wrote:
Another problem I see is the #submitButton, that is outside the form
that you added with #addValidatedForm. To get your 'done' button into
the form you might want to customize the decorator like:
... addValidatedForm: #( save cancel done )
Lukas -- what if I just want the plain version (save,cancel) but still
want
to know which button was pressed.. I really only had the 'done' button
in place since that is what the examples used. So, if I ditch the
'done'
button, how can I get the ultimate answer that was selected?
Btw, #save answers the changed model and #cancel answers nil.
I saw that onAnswer was called for the cancel action but didn't get a
breakpoint
in the onAnswer block when 'save' was selected.. Do I just assume that
if my
block isn't triggered that 'save' was selected?
Sorry for being dense.. I just want to make sure I've got sufficient
info for this
tonight when I want to work on this more.
-- Rick
4:21 p.m.
Btw, #save
answers the changed model and #cancel answers nil.
I saw that onAnswer was called for the cancel action but didn't get
a breakpoint
in the onAnswer block when 'save' was selected.. Do I just assume
that if my
block isn't triggered that 'save' was selected?
5:36 p.m.
On Tue, August 19, 2008 7:21 am, Lukas Renggli wrote:
I guess this has to do with the other bugs you had in your code ;-)
An #onAnswer: block like this should actually work:
[ :answer |
answer isNil
ifTrue: [ self inform: 'You cancelled editing' ]
ifFalse: [ self inform: 'The object was saved: ' , answer
printString ] ]
Thanks Lukas! I will modify the code tonight to 'fix' the bugs you
mentioned.. I had code like that last night but everytime I hit the 'save'
or 'cencel' button, Seaside could complain about my #children being messed
up or misconfigured. I had created a #children method on my above
MSWLI_Contact object in addition to my main application class that also
answers #children with about a dozen or so classes listed -- do I need to
only have a single #children in my entire object hierarchy or am I allowed
to have some objects add children at run-time? When I had the runtime
variant initially set to return 'nil' for children at startup and then
changed to return a real value once a user logged in, that was still failing
the children test w/ Seaside.. Anyway, I know I've got a bug but am not
exactly sure how to make Seaside happy. One of my permutations last night
was rendering empty Magritte forms for some reason -- never figured that one
out but it was related to building my #component inst variable at the wrong
time apparently.. Anyway, I'm trying to find the happy medium so I can
continue on with more productive work! Thanks for all the help you all!
-- Rick
Btw, #save answers the changed model and #cancel
answers nil.
I saw that onAnswer was called for the cancel action but didn't get
a breakpoint
in the onAnswer block when 'save' was selected.. Do I just assume
that if my
block isn't triggered that 'save' was selected?
5739
days inactive
5739
days old
8 comments
4 participants
participants (4)
-
Lukas Renggli -
merlyn＠stonehenge.com -
Richard E. Flower -
Rick Flower