WASelectTag

I'm using Seaside 2.7b1 to render a form that posts to an external  
payment processing website.

It looks like WASelectTag is missing the #name: method that all of  
the other form elements have. I can work around it easily enough, but  
then I encounter another problem. This code doesn't generate the  
result I was expecting:

        (html select)
                attributeAt: 'name' put: 'PaymentType';
                list: #('CREDIT' 'CHECK');
                labels: [:each | each asLowercase raiseFirst]

I expected option tags like this:

        <option value='CREDIT'>Credit</option>

But instead, I get:

        <option>Credit</option>

If I try to generate the option tags themselves, I discover that they  
don't understand #value:. I suppose I can employ the same  
attributeAt:put: trick in there, but it feels like I'm working  
against the intended design here.

Is there a better way to do this, or have I stumbled upon a bug/
oversight? I realize that you usually don't need to set these  
explicitly, since the callback framework handles those details. But  
in this case, I really do need to specify them, and the other form  
inputs are working nicely.

--
Ken Treis
Miriam Technologies, Inc.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

The design is that you let Seaside figure out the callback names,
values, etc. In your case there is nothing that Seaside can help you.
It cannot know what your external service is expecting.

So yes, you to manually generate the option tags and use #attributeAt:put:

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

OK, I can do this.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Jun 6, 2007, at 9:46 AM, Michel Bany wrote:

> Why aren't you using #callback: instead and let Seaside do the low  
> level html stuff?

Because this form has to post to a 3rd party payment processing site.  
Sorry, I mentioned that was in my original message but deleted it in  
the reply quotes.

Since I have to build the form "by hand", but I like the programmatic  
HTML generation in Seaside, I thought I'd see how far I could get  
with it. Everything worked the way I expected until I got to the  
<select> tag.

--
Ken Treis
Miriam Technologies, Inc.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Can we add the trivial helpers for WASelectTag>>name: and
> WAOptionTag>>value: ? The other form input tags have them. I have added them
> as extensions in my VisualWorks package, but it seems that they belong in
> the base. It'd be more consistent with the other form input tags.

They are in the latest Seaside 2.8. Again some more code duplication ...

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Jun 6, 2007, at 10:41 AM, Lukas Renggli wrote:

>> Can we add the trivial helpers for WASelectTag>>name: and
>> WAOptionTag>>value: ? The other form input tags have them. I have  
>> added them
>> as extensions in my VisualWorks package, but it seems that they  
>> belong in
>> the base. It'd be more consistent with the other form input tags.
>
> They are in the latest Seaside 2.8. Again some more code  
> duplication ...

Thanks Lukas.

I know (at some point) people were holding out for traits to solve  
this, but it seems like a lot of these helpers could simply be pushed  
up to WATagBrush. Things like name, value, type, etc. all fall under  
the category of "common attribute helpers" that several (but not all)  
tags need.

The protocols wouldn't be as clearly documented for each individual  
tag, but personally I'd rather take the tradeoff if we could reduce  
code duplication.

--
Ken Treis
Miriam Technologies, Inc.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Ken,
I see, then I'll need to update Seaside 2.7b1 in the VW public store.
I'll post when this is ready.
Sorry that I overlooked your initial email.
Cheers,
Michel.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/6/6, Ken Treis <[hidden email]>:
Yeah right, at the end WATagBrush will look like Object in Squeak.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Jun 7, 2007, at 5:44 AM, Philippe Marschall wrote:

> 2007/6/6, Ken Treis <[hidden email]>:
>> I know (at some point) people were holding out for traits to solve
>> this, but it seems like a lot of these helpers could simply be pushed
>> up to WATagBrush. Things like name, value, type, etc. all fall under
>> the category of "common attribute helpers" that several (but not all)
>> tags need.
>
> Yeah right, at the end WATagBrush will look like Object in Squeak.

This is interesting to me. I don't quite know what your objection is,  
but it sounds like you'd rather have the code duplication than have  
the protocol space of WATagBrush grow. I'd personally much rather  
eliminate the duplicated code.

But it's just a personal preference, for whatever it's worth. The  
only reason I mentioned it was because I sympathized with Lukas's  
laments over the additional duplicated code. It seems like there's a  
simple answer here, but apparently I'm in the minority that doesn't  
find it objectionable.

--
Ken Treis
Miriam Technologies, Inc.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 6/8/07, Ken Treis <[hidden email]> wrote:

> But it's just a personal preference, for whatever it's worth. The
> only reason I mentioned it was because I sympathized with Lukas's
> laments over the additional duplicated code. It seems like there's a
> simple answer here, but apparently I'm in the minority that doesn't
> find it objectionable.

FWIW, I am also in that minority.

Avi
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Same here, mostly because there are tools available to let you know when
you'd used an attribute that is not applicable to a given element, so
having a bunch very high isn't the worst that could happen,

http://users.skynet.be/mgueury/mozilla/

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside