That's a good point about the mini-controllers--
>From experimenting with going stateless in JSF, and Adam's work on state
>saving deltas, we allow the view to be created up front with Facelets-- from
>file-- fresh on a request. So even without any viewstate passed, you
>basically get a snapshot of the same, declarative, tree for processing
>updates/validators/actions/etc.
So you would be able to process a request like:
/search.jsf?myForm:queryInput=adam%20winer
With some of the AJAX stuff, I've been toying around with the idea of
'observers'-- components that exist, but don't render anything, so when generic
html posts, these invisible components would actually take care of processing
the request. In some ways, I think this might apply to restful types of calls.
-- Jacob
>Hi!
>
>Just to make sure we talk about the same.
>We have the place where we create a bookmarkable link - which can be the
>NavigationHandler - and we have the place where we have to process the
>incoming get parameters.
>
>> You can either put that metadata in the view - where it doesn't fit well -
>or
>> in the controller/NavigationHandler layer - where it fits naturally.
>>
>To the "Process" part:
>
>I dont understand whats the difference between user-input and url-input
>- but are from external and are subject to be wrong.
>Both should go through the whole validator/converter stuff in JSF.
>
>We need a way to handle all this, so why not do it through the view. All
>what we need is in place there.
>
>Else we have to create another jsp/facelete like configuration for this
>"mini-view".
>And then still we need the real view the bookmark url points to - JSF
>needs something to show.
>
>> That means a custom NavigationHandler with a new configuration
>> file.
>>
>
>The "Create" part:
>To create a bookmarkable link we do not need much more than the propose
>in my post - somethink like toViewId=/view.jsp?param=#{...}
>
>Ciao,
>Mario
>
