+1 On Thu, May 6, 2010 at 5:43 PM, Mike Kienenberger <[email protected]> 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 <[email protected]> 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 <[email protected] >>> <mailto:[email protected]>> 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
