determining "save" or "cancel" status on #rendered Magritte component...

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


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

> 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.

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


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

>>>>> "Lukas" == Lukas Renggli <[hidden email]> 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
<[hidden email]> <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

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

>> 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?

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 ] ]

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

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


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

>>>>> "Lukas" == Lukas Renggli <[hidden email]> 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
<[hidden email]> <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

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

On Tue, August 19, 2008 7:21 am, Lukas Renggli wrote:
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



_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

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


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki