I see.
In this instance I would probably want to evaluate how fields are currently
focused in tapestry.
The form component appears to be doing a lot of work around field focus. It
may be the case that it makes more sense to have a generic
IFormComponent.grabFocus() method to handle this instead.
Perhaps even a grabFocus(boolean override) method to state that you want the
form component to forget whatever focus logic it may be using and guarantee
that your field gets focus .( somehow) .
Basic point, I don't know if this makes sense to have in the ResponseBuilder
kind of logic, but this is good. It's exactly why I wanted more details :)
If someone can take a look at
http://tapestry.apache.org/tapestry4.1/components/Form.html and come up with
some parameters for how that focus parameter should work in concert with
individual field focus attributes we might be able to find an easy solution.
P.S. Keep em coming, I appreciate any input people have to make the
framework better. :)
On 8/23/06, Ron Piterman <[EMAIL PROTECTED]> wrote:
To give one an impression, Here is a code snippet from our application:
/**
* sends an ajax action to focus the given field.
* @param formField
*/
protected void focus( IFormComponent formField ) {
this.getAjaxRenderer(true).add(
ResponseActionConstants.DO_DELEGATE_NODE,
new FormComponentIdRenderer( formField ),
"focus" );
}
The Response renderer renders an xml response.
The Javascript which processes this xml will do a lookup for the node
with the given ID (the ID is rendered into the response by the
FormComponentIDRenderer), and perform "focus()" on it.
This snippet can be easily done also by a tapestry script file - only it
would involve much more code.
Note that if after the "focus" additionaly IRenderer are passed to the
AjaxRenderer.add method, their rendering will be passed to the focus
method as parameters. Is this possible with 4.1 ?
Cheers,
Ron
Jesse Kuhnert wrote:
> Hi Ron,
>
> I definitely welcome any feedback people may have.
>
> It's obvious that I haven't spent nearly as much time on
components/widgets
> as I have been on general infrastructure.
>
> If you have a specific problem or two in mind I can try to come up with
> solutions, but with only solutions I'm going to have a hard time
> visualizing
> everything properly.
>
> Please feel free to chirp up with more specifics, I do value your input
> very
> much. (as you have been doing this for as long as I have I think ..)
>
> On 8/22/06, Ron Piterman <[EMAIL PROTECTED]> wrote:
>
>>
>> Hi all -
>>
>> The 4.1 version seems very exciting: the @EventListener annotation is
>> really cool and easy to use.
>>
>> Currently I am working on a Project with a very extensive use of XHR
>> using Dojo and currently Tapestry 4.0
>>
>> In evaluating 4.1 it seems to me, a great work has been done to enable
>> render and process XHRs - it seems to me however that some
*abstraction*
>> and *extensibility* is missing.
>>
>> Talking concrete:
>>
>> The ResponseBuilder (Dojo, Default, JSON) are built around an Interface
>> that enables these three.
>>
>> The Tapestry Javascript Response renderer (tapestry.load) handles a few
>> actions : JavaScript processing and "replace by id".
>>
>> I would suggest making both response builder implementations and
>> tapestry.load more extendable, adding pluggable actions to both.
>>
>> Cheers,
>> Ron
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
