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 >> >> >> >> > > >
