You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Ali Ok <al...@aliok.com.tr> on 2010/05/05 20:01:39 UTC
[GSOC] New Form Elements
Hi all,
I've been working on my GSOC project (prototyping currently). I want to ask
you something.
With HTML5, form elements does not have to be children of a form. Of course,
that is the preferred way, but you can set the "form" attribute of the
<input> and that <input> will be posted when the owner form is submitted.[0]
This also applies to submit buttons, in a similar way. You can define "form"
attribute of the submit button, and it will submit the defined form -not
necessarily its parent- when it is clicked.[1]
So, I wonder if this can be applied in JSF side. AFAIK currently, a
commandButton needs to be under a <h:form>.
This is also about serverside component tree, and maybe state saving.
I couldn't set up much in my head.
What do you think? How can we use this new features? How to model them?
Thanks,
Ali
[0]
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fae-form
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#submit-button-state<http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#submit-button-state>
--
My Blog: http://blog.aliok.com.tr
Twitter: http://twitter.com/aliok_tr
Re: [GSOC] New Form Elements
Posted by Ali Ok <al...@aliok.com.tr>.
Hi,
Thanks for the replies.
>> But also you might get it easier (second option),
> >> maybe you wont even need a second lifecycle if you can tackle the
> >> problem via JSF2 system events on the controls themselves.
>
Sounds good :)
>> I would recommend also to raise a spec issue there regarding this.
>
I will do it after some research.
Thanks,
Ali
On Thu, May 6, 2010 at 6:43 PM, Mike Kienenberger <mk...@gmail.com>wrote:
> Sounds a lot like the tomahawk sandbox subform and tomahawk UICommand
> components. You can specify an "actionFor" attribute on the UICommand
> components to point at a specific subform.
>
> I wonder if some of the design from subform can be reused.
>
> On Thu, May 6, 2010 at 10:39 AM, Werner Punz <we...@gmail.com>
> wrote:
> > Yes they will definitely need that attribute especially if they are
> outside
> > of a form. Also the components have to throw an error if the attribute is
> > not set and if they are not hosted inside of a form.
> >
> >
> > Werner
> >
> >
> >
> >
> > Am 06.05.10 16:25, schrieb Kito Mann:
> >>
> >> On Thu, May 6, 2010 at 4:19 AM, Werner Punz <werner.punz@gmail.com
> >> <ma...@gmail.com>> wrote:
> >>
> >> 2 Possibilities:
> >> First, via custom lifecycle, extend the standard elements in a way
> >> that they refer to a form element and a first step collect those
> >> elements and a second step at, form processing, processes those
> >> external elements within the bounds of a form.
> >> This applies to the apply request values and validation phases, or
> >> probably.
> >>
> >> Second possibility:
> >>
> >> But also you might get it easier (second option),
> >> maybe you wont even need a second lifecycle if you can tackle the
> >> problem via JSF2 system events on the controls themselves.
> >> (you can set direct event listeners for various phases on the
> controls
> >> so that they will be processed), this would be even faster since the
> >> event handling mechanisms would do the bookkeeping for you which you
> >> in the other case would have to do yourself.
> >>
> >>
> >> Using component system events should work fine -- it's how
> >> <h:outputScript> and <h:outputStylesheet> can retarget themselves to the
> >> <h:head> component. I think the components may need a new "forForm"
> >> attribute, though, for cases when there's more than one form on the
> page.
> >>
> >>
> >> This is probably the biggest problem with JSF and HTML5 (I did not
> >> know this was possible, since I only follow the html 5 development
> >> via blogs and articles), I would recommend also to raise a spec
> >> issue there regarding this, so that we might, special handling for
> >> the official spec so that no impl has to cook its own mechnanism in
> >> the long run.
> >>
> >>
> https://javaserverfaces-spec-public.dev.java.net/servlets/ProjectIssues
> >>
> >>
> >> Werner
> >>
> >>
> >>
> >> Am 05.05.10 20:01, schrieb Ali Ok:
> >>
> >> Hi all,
> >> I've been working on my GSOC project (prototyping currently). I
> >> want to
> >> ask you something.
> >>
> >> With HTML5, form elements does not have to be children of a form.
> >> Of
> >> course, that is the preferred way, but you can set the "form"
> >> attribute
> >> of the <input> and that <input> will be posted when the owner
> >> form is
> >> submitted.[0]
> >> This also applies to submit buttons, in a similar way. You can
> >> define
> >> "form" attribute of the submit button, and it will submit the
> >> defined
> >> form -not necessarily its parent- when it is clicked.[1]
> >>
> >> So, I wonder if this can be applied in JSF side. AFAIK currently,
> a
> >> commandButton needs to be under a <h:form>.
> >> This is also about serverside component tree, and maybe state
> >> saving.
> >>
> >> I couldn't set up much in my head.
> >>
> >> What do you think? How can we use this new features? How to
> >> model them?
> >>
> >> Thanks,
> >> Ali
> >>
> >> [0]
> >>
> >>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fae-form
> >> [1]
> >>
> >>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#submit-button-state
> >>
> >> <
> http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#submit-button-state
> >
> >>
> >> --
> >> My Blog: http://blog.aliok.com.tr
> >> Twitter: http://twitter.com/aliok_tr
> >>
> >>
> >>
> >>
> >
> >
> >
>
--
My Blog: http://blog.aliok.com.tr
Twitter: http://twitter.com/aliok_tr
Re: [GSOC] New Form Elements
Posted by Martin Marinschek <mm...@apache.org>.
> On Thu, May 6, 2010 at 5:43 PM, Mike Kienenberger <mk...@gmail.com>
> wrote:
>> Sounds a lot like the tomahawk sandbox subform and tomahawk UICommand
>> components. You can specify an "actionFor" attribute on the UICommand
>> components to point at a specific subform.
>>
>> I wonder if some of the design from subform can be reused.
Yes, I agree - you definitely need to take a look at the subform - if
for nothing else to find out if the code will be superfluous with HTML
5 ;)
best regards,
Martin
Re: [GSOC] New Form Elements
Posted by Matthias Wessendorf <ma...@apache.org>.
+1
On Thu, May 6, 2010 at 5:43 PM, Mike Kienenberger <mk...@gmail.com> wrote:
> Sounds a lot like the tomahawk sandbox subform and tomahawk UICommand
> components. You can specify an "actionFor" attribute on the UICommand
> components to point at a specific subform.
>
> I wonder if some of the design from subform can be reused.
>
> On Thu, May 6, 2010 at 10:39 AM, Werner Punz <we...@gmail.com> wrote:
>> Yes they will definitely need that attribute especially if they are outside
>> of a form. Also the components have to throw an error if the attribute is
>> not set and if they are not hosted inside of a form.
>>
>>
>> Werner
>>
>>
>>
>>
>> Am 06.05.10 16:25, schrieb Kito Mann:
>>>
>>> On Thu, May 6, 2010 at 4:19 AM, Werner Punz <werner.punz@gmail.com
>>> <ma...@gmail.com>> wrote:
>>>
>>> 2 Possibilities:
>>> First, via custom lifecycle, extend the standard elements in a way
>>> that they refer to a form element and a first step collect those
>>> elements and a second step at, form processing, processes those
>>> external elements within the bounds of a form.
>>> This applies to the apply request values and validation phases, or
>>> probably.
>>>
>>> Second possibility:
>>>
>>> But also you might get it easier (second option),
>>> maybe you wont even need a second lifecycle if you can tackle the
>>> problem via JSF2 system events on the controls themselves.
>>> (you can set direct event listeners for various phases on the controls
>>> so that they will be processed), this would be even faster since the
>>> event handling mechanisms would do the bookkeeping for you which you
>>> in the other case would have to do yourself.
>>>
>>>
>>> Using component system events should work fine -- it's how
>>> <h:outputScript> and <h:outputStylesheet> can retarget themselves to the
>>> <h:head> component. I think the components may need a new "forForm"
>>> attribute, though, for cases when there's more than one form on the page.
>>>
>>>
>>> This is probably the biggest problem with JSF and HTML5 (I did not
>>> know this was possible, since I only follow the html 5 development
>>> via blogs and articles), I would recommend also to raise a spec
>>> issue there regarding this, so that we might, special handling for
>>> the official spec so that no impl has to cook its own mechnanism in
>>> the long run.
>>>
>>> https://javaserverfaces-spec-public.dev.java.net/servlets/ProjectIssues
>>>
>>>
>>> Werner
>>>
>>>
>>>
>>> Am 05.05.10 20:01, schrieb Ali Ok:
>>>
>>> Hi all,
>>> I've been working on my GSOC project (prototyping currently). I
>>> want to
>>> ask you something.
>>>
>>> With HTML5, form elements does not have to be children of a form.
>>> Of
>>> course, that is the preferred way, but you can set the "form"
>>> attribute
>>> of the <input> and that <input> will be posted when the owner
>>> form is
>>> submitted.[0]
>>> This also applies to submit buttons, in a similar way. You can
>>> define
>>> "form" attribute of the submit button, and it will submit the
>>> defined
>>> form -not necessarily its parent- when it is clicked.[1]
>>>
>>> So, I wonder if this can be applied in JSF side. AFAIK currently, a
>>> commandButton needs to be under a <h:form>.
>>> This is also about serverside component tree, and maybe state
>>> saving.
>>>
>>> I couldn't set up much in my head.
>>>
>>> What do you think? How can we use this new features? How to
>>> model them?
>>>
>>> Thanks,
>>> Ali
>>>
>>> [0]
>>>
>>> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fae-form
>>> [1]
>>>
>>> http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#submit-button-state
>>>
>>> <http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#submit-button-state>
>>>
>>> --
>>> My Blog: http://blog.aliok.com.tr
>>> Twitter: http://twitter.com/aliok_tr
>>>
>>>
>>>
>>>
>>
>>
>>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: [GSOC] New Form Elements
Posted by Mike Kienenberger <mk...@gmail.com>.
Sounds a lot like the tomahawk sandbox subform and tomahawk UICommand
components. You can specify an "actionFor" attribute on the UICommand
components to point at a specific subform.
I wonder if some of the design from subform can be reused.
On Thu, May 6, 2010 at 10:39 AM, Werner Punz <we...@gmail.com> wrote:
> Yes they will definitely need that attribute especially if they are outside
> of a form. Also the components have to throw an error if the attribute is
> not set and if they are not hosted inside of a form.
>
>
> Werner
>
>
>
>
> Am 06.05.10 16:25, schrieb Kito Mann:
>>
>> On Thu, May 6, 2010 at 4:19 AM, Werner Punz <werner.punz@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>> 2 Possibilities:
>> First, via custom lifecycle, extend the standard elements in a way
>> that they refer to a form element and a first step collect those
>> elements and a second step at, form processing, processes those
>> external elements within the bounds of a form.
>> This applies to the apply request values and validation phases, or
>> probably.
>>
>> Second possibility:
>>
>> But also you might get it easier (second option),
>> maybe you wont even need a second lifecycle if you can tackle the
>> problem via JSF2 system events on the controls themselves.
>> (you can set direct event listeners for various phases on the controls
>> so that they will be processed), this would be even faster since the
>> event handling mechanisms would do the bookkeeping for you which you
>> in the other case would have to do yourself.
>>
>>
>> Using component system events should work fine -- it's how
>> <h:outputScript> and <h:outputStylesheet> can retarget themselves to the
>> <h:head> component. I think the components may need a new "forForm"
>> attribute, though, for cases when there's more than one form on the page.
>>
>>
>> This is probably the biggest problem with JSF and HTML5 (I did not
>> know this was possible, since I only follow the html 5 development
>> via blogs and articles), I would recommend also to raise a spec
>> issue there regarding this, so that we might, special handling for
>> the official spec so that no impl has to cook its own mechnanism in
>> the long run.
>>
>> https://javaserverfaces-spec-public.dev.java.net/servlets/ProjectIssues
>>
>>
>> Werner
>>
>>
>>
>> Am 05.05.10 20:01, schrieb Ali Ok:
>>
>> Hi all,
>> I've been working on my GSOC project (prototyping currently). I
>> want to
>> ask you something.
>>
>> With HTML5, form elements does not have to be children of a form.
>> Of
>> course, that is the preferred way, but you can set the "form"
>> attribute
>> of the <input> and that <input> will be posted when the owner
>> form is
>> submitted.[0]
>> This also applies to submit buttons, in a similar way. You can
>> define
>> "form" attribute of the submit button, and it will submit the
>> defined
>> form -not necessarily its parent- when it is clicked.[1]
>>
>> So, I wonder if this can be applied in JSF side. AFAIK currently, a
>> commandButton needs to be under a <h:form>.
>> This is also about serverside component tree, and maybe state
>> saving.
>>
>> I couldn't set up much in my head.
>>
>> What do you think? How can we use this new features? How to
>> model them?
>>
>> Thanks,
>> Ali
>>
>> [0]
>>
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fae-form
>> [1]
>>
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#submit-button-state
>>
>> <http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#submit-button-state>
>>
>> --
>> My Blog: http://blog.aliok.com.tr
>> Twitter: http://twitter.com/aliok_tr
>>
>>
>>
>>
>
>
>
Re: [GSOC] New Form Elements
Posted by Werner Punz <we...@gmail.com>.
Yes they will definitely need that attribute especially if they are
outside of a form. Also the components have to throw an error if the
attribute is not set and if they are not hosted inside of a form.
Werner
Am 06.05.10 16:25, schrieb Kito Mann:
>
> On Thu, May 6, 2010 at 4:19 AM, Werner Punz <werner.punz@gmail.com
> <ma...@gmail.com>> wrote:
>
> 2 Possibilities:
> First, via custom lifecycle, extend the standard elements in a way
> that they refer to a form element and a first step collect those
> elements and a second step at, form processing, processes those
> external elements within the bounds of a form.
> This applies to the apply request values and validation phases, or
> probably.
>
> Second possibility:
>
> But also you might get it easier (second option),
> maybe you wont even need a second lifecycle if you can tackle the
> problem via JSF2 system events on the controls themselves.
> (you can set direct event listeners for various phases on the controls
> so that they will be processed), this would be even faster since the
> event handling mechanisms would do the bookkeeping for you which you
> in the other case would have to do yourself.
>
>
> Using component system events should work fine -- it's how
> <h:outputScript> and <h:outputStylesheet> can retarget themselves to the
> <h:head> component. I think the components may need a new "forForm"
> attribute, though, for cases when there's more than one form on the page.
>
>
> This is probably the biggest problem with JSF and HTML5 (I did not
> know this was possible, since I only follow the html 5 development
> via blogs and articles), I would recommend also to raise a spec
> issue there regarding this, so that we might, special handling for
> the official spec so that no impl has to cook its own mechnanism in
> the long run.
>
> https://javaserverfaces-spec-public.dev.java.net/servlets/ProjectIssues
>
>
> Werner
>
>
>
> Am 05.05.10 20:01, schrieb Ali Ok:
>
> Hi all,
> I've been working on my GSOC project (prototyping currently). I
> want to
> ask you something.
>
> With HTML5, form elements does not have to be children of a form. Of
> course, that is the preferred way, but you can set the "form"
> attribute
> of the <input> and that <input> will be posted when the owner
> form is
> submitted.[0]
> This also applies to submit buttons, in a similar way. You can
> define
> "form" attribute of the submit button, and it will submit the
> defined
> form -not necessarily its parent- when it is clicked.[1]
>
> So, I wonder if this can be applied in JSF side. AFAIK currently, a
> commandButton needs to be under a <h:form>.
> This is also about serverside component tree, and maybe state
> saving.
>
> I couldn't set up much in my head.
>
> What do you think? How can we use this new features? How to
> model them?
>
> Thanks,
> Ali
>
> [0]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fae-form
> [1]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#submit-button-state
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#submit-button-state>
>
> --
> My Blog: http://blog.aliok.com.tr
> Twitter: http://twitter.com/aliok_tr
>
>
>
>
Re: [GSOC] New Form Elements
Posted by Kito Mann <ki...@virtua.com>.
On Thu, May 6, 2010 at 4:19 AM, Werner Punz <we...@gmail.com> wrote:
> 2 Possibilities:
> First, via custom lifecycle, extend the standard elements in a way that
> they refer to a form element and a first step collect those elements and a
> second step at, form processing, processes those external elements within
> the bounds of a form.
> This applies to the apply request values and validation phases, or
> probably.
>
> Second possibility:
>
> But also you might get it easier (second option),
> maybe you wont even need a second lifecycle if you can tackle the problem
> via JSF2 system events on the controls themselves.
> (you can set direct event listeners for various phases on the controls
> so that they will be processed), this would be even faster since the event
> handling mechanisms would do the bookkeeping for you which you in the other
> case would have to do yourself.
>
Using component system events should work fine -- it's how <h:outputScript>
and <h:outputStylesheet> can retarget themselves to the <h:head> component.
I think the components may need a new "forForm" attribute, though, for cases
when there's more than one form on the page.
>
> This is probably the biggest problem with JSF and HTML5 (I did not know
> this was possible, since I only follow the html 5 development via blogs and
> articles), I would recommend also to raise a spec issue there regarding
> this, so that we might, special handling for the official spec so that no
> impl has to cook its own mechnanism in the long run.
>
> https://javaserverfaces-spec-public.dev.java.net/servlets/ProjectIssues
>
>
> Werner
>
>
>
> Am 05.05.10 20:01, schrieb Ali Ok:
>
> Hi all,
>> I've been working on my GSOC project (prototyping currently). I want to
>> ask you something.
>>
>> With HTML5, form elements does not have to be children of a form. Of
>> course, that is the preferred way, but you can set the "form" attribute
>> of the <input> and that <input> will be posted when the owner form is
>> submitted.[0]
>> This also applies to submit buttons, in a similar way. You can define
>> "form" attribute of the submit button, and it will submit the defined
>> form -not necessarily its parent- when it is clicked.[1]
>>
>> So, I wonder if this can be applied in JSF side. AFAIK currently, a
>> commandButton needs to be under a <h:form>.
>> This is also about serverside component tree, and maybe state saving.
>>
>> I couldn't set up much in my head.
>>
>> What do you think? How can we use this new features? How to model them?
>>
>> Thanks,
>> Ali
>>
>> [0]
>>
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fae-form
>> [1]
>>
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#submit-button-state
>> <
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#submit-button-state
>> >
>>
>> --
>> My Blog: http://blog.aliok.com.tr
>> Twitter: http://twitter.com/aliok_tr
>>
>>
>
>
Re: [GSOC] New Form Elements
Posted by Werner Punz <we...@gmail.com>.
2 Possibilities:
First, via custom lifecycle, extend the standard elements in a way that
they refer to a form element and a first step collect those elements and
a second step at, form processing, processes those external elements
within the bounds of a form.
This applies to the apply request values and validation phases, or probably.
Second possibility:
But also you might get it easier (second option),
maybe you wont even need a second lifecycle if you can tackle the
problem via JSF2 system events on the controls themselves.
(you can set direct event listeners for various phases on the controls
so that they will be processed), this would be even faster since the
event handling mechanisms would do the bookkeeping for you which you in
the other case would have to do yourself.
This is probably the biggest problem with JSF and HTML5 (I did not know
this was possible, since I only follow the html 5 development via blogs
and articles), I would recommend also to raise a spec issue there
regarding this, so that we might, special handling for the official spec
so that no impl has to cook its own mechnanism in the long run.
https://javaserverfaces-spec-public.dev.java.net/servlets/ProjectIssues
Werner
Am 05.05.10 20:01, schrieb Ali Ok:
> Hi all,
> I've been working on my GSOC project (prototyping currently). I want to
> ask you something.
>
> With HTML5, form elements does not have to be children of a form. Of
> course, that is the preferred way, but you can set the "form" attribute
> of the <input> and that <input> will be posted when the owner form is
> submitted.[0]
> This also applies to submit buttons, in a similar way. You can define
> "form" attribute of the submit button, and it will submit the defined
> form -not necessarily its parent- when it is clicked.[1]
>
> So, I wonder if this can be applied in JSF side. AFAIK currently, a
> commandButton needs to be under a <h:form>.
> This is also about serverside component tree, and maybe state saving.
>
> I couldn't set up much in my head.
>
> What do you think? How can we use this new features? How to model them?
>
> Thanks,
> Ali
>
> [0]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fae-form
> [1]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#submit-button-state
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#submit-button-state>
>
> --
> My Blog: http://blog.aliok.com.tr
> Twitter: http://twitter.com/aliok_tr
>