Hi Craig,so you think it is better that we have another implementation of lifecyles for JSF portlets,(from scratch or using decoratore around current class) which can support both ActionRequest and RenderRequest and map them to different neccessary phases of JSF, one mapping for those who get
Putting the article in the wiki sounds like a good idea to me. Everybody
would have the possiblility of adding information and we would hopefully
also have a nice collection of information for new users.
btw. I'd also be interested in writing
regards
Ernst
On 10/26/06, Arash Rajaeeyan [EMAIL
Cool stuff,
there is also a similar new serachengine
http://www.krugle.com/
where you can search for code and projects
On 10/26/06, Kito D. Mann [EMAIL PROTECTED] wrote:
One of the coolest things I noticed in my vanity search was that it looks
inside zip files:
great idea,
maybe we could put the examples right after or before the screen shots
I have the impression, that many users like to first see an example
and then read additional information
regards
Ernst
On 10/27/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote:
Hello All,
I want to synchronize the
Hi!
At the moment when no navigation case for an outcome is found
the navigationHandler decides to stay at the same view. I think
an option for web.xml would be useful to tell the navigationHandler
if no navigation case for an outcome is found, but the outcome
matches a viewId to navigate to
I think this is a bad idea for following reasons:1) it is against the spec behaviour2) since in JSF 1.1 navigation outcomes are string it is completely possible for a programmer to have a syntax error in out comes
3) this make confusion between page names and outcomes (navigation events)4) I think
SelectOneChoiceRenderer, SelectOneListboxRenderer and SelectManyListboxRenderer
should support SelectItemGroup
--
Key: TOBAGO-165
URL:
1) it is against the spec behaviour
Of course you are absolutely right with this
therefore I'd make it an optional feature, being able to turn it on with a
configuration parameters
2) since in JSF 1.1 navigation outcomes are string it is completely possible
for a programmer to have a syntax
2) since in JSF 1.1 navigation outcomes are string it is completely possible
for a programmer to have a syntax error in out comes
Sorry don't get your point here, if an action returns a misspelled outcome
or a misspelled viewId you would not want to navigate in both cases right?
I think he
You're right, an alternate NavigationHandler shipped with MyFaces
is probably the better choice let's go with that approach.
thanks for your ideas
On 10/29/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
2) since in JSF 1.1 navigation outcomes are string it is completely possible
for a
alternate NavigationHandler to support viewIds as outcome
-
Key: MYFACES-1482
URL: http://issues.apache.org/jira/browse/MYFACES-1482
Project: MyFaces Core
Issue Type: New Feature
Ernst, you also wanna check some of the *extensions* in the MyFAcesNH_Impl
for accessing navigation cases. It is important in security cases to
*check* navigation cases ...
so your impl could benefit from that !
On 10/29/06, Ernst Fastl [EMAIL PROTECTED] wrote:
You're right, an alternate
12 matches
Mail list logo
