Sorry I didn't respond earlier. It's been a busy day. The ultimate constraints wer're working under for this is:
-) Don't want to have actual _javascript_ code embedded on the component in questions "onChange" etc attributes because they don't actually fire off valid _javascript_ events. Valid _javascript_ events are needed for my workaround with Forms and the validation framework. It's sort of like the enhancement workers in that it's not an ideal solution, but sort of good enough for now. It's also limiting in that only one event can be bound to the "onchange" parameter of the component.
-) Using on<whatever> also presents problems because we can't effectively type off of the attribute name, or at least it will get very messy very fast. Which events do we "look" for in the attribute? I can see inefficient if blocks checking tons of values already. :(
The implementation problems are solvable, I just don't see a reasonable way of doing it currently without code modifications to tapestry.
Since all of the form stuff already has built-in cool dhtml validation effects on the client side, it is my hope that this feature won't be used by as many people as the others?
People are already used to things like listeners/actions being attributes in tapestry. I think if we make it look and feel very close to that concept it will be equally as familiar as "onchange" will be. At least I hope so.
I'm not poo poo-ing the idea, I just don't see a better alternative that can be completed in a reasonable amount of time for the alpha-7 release. Maybe there is one? I would rather spend more time on fixing all of these other little things and let this eyesore remain (with the proposed changes of course) for now at least, hoping to spend more quality design thoughts on the next alpha-8 release which should hopefully introduce a couple new very slight changes into tapestry that will make things a lot easier?
On 11/28/05, Leonardo Quijano Vincenzi <[EMAIL PROTECTED]> wrote:
On second thought Jesse, isn't it a bit more intuitive if we use the
HTML convention (onchange, onsubmit)?
<span jwcid="[EMAIL PROTECTED]:AjaxEvent" all the params you need
here... />
<span jwcid="@Radio" />
I think this should be as straightforward as possible for developers
using the framework. An HTML would think "I need to fire an event when
my field changes", and what's the obvious answer... "use the onevent
handler".
Maybe we could even fire several events:
<span jwcid="@Radio" changeField2}" />
Now, maybe there's some problem at the inside (Dojo conflicts and the
things you said). I think we have 2 questions here:
1) Implementation problems notwithstanding, is this the best model? I
think is the easiest and most obvious to the people with HTML /
_javascript_ knowledge..
2) The implementations problems can be solved. If so, how ?
--
Ing. Leonardo Quijano Vincenzi
DTQ Software
Leonardo Quijano Vincenzi wrote:
> Looks better! Sometime ago I thought of a 3-part compromise on this
> (the script component, the textfield component, and a binding
> component). Something like this:
>
> <span jwcid="[EMAIL PROTECTED]:AjaxFieldObserver" all the params
> you need here... />
> <span jwcid="[EMAIL PROTECTED]:AjaxFieldObserver" all the params
> you need here... />
>
> <span jwcid="@Radio" />
>
> <span jwcid="@Bind" field="radio" event="onchange"
> observer="fieldobserver1" />
>
> Now, maybe that's just overkill. But it could eventually be useful.
>
> Perhaps my original solution was limited too in the sense that it
> doesn't allow several observers per event (and it could break any
> special handlers that are defined the 'dojo way', right ?
>
> Right now my yesterday build of Tacos is working for me in my app in
> development, so I think I have time to sort out the best way to
> include this sort of functionality in Tacos.
>
> Now, of course, note that "observeEvent" is a bit higher in the
> learning curve that just using onchange. But it seems nice. Perhaps
> someone will put an additional thought on this later, too. That's what
> open source is for...
>
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Tacos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tacos-devel
