On 1/31/06, Martin Marinschek [EMAIL PROTECTED] wrote:
By the way - any update on the optional validator stuff together with
partial validation? Ok, maybe we should start a different thread on
this ;)
I finally got around to updating the wiki page.
The short answer is that it works fine as
Does it require API changes or would it break the TCK if we would go
1.2 compatible here?
regards,
Martin
On 2/8/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
On 1/31/06, Martin Marinschek [EMAIL PROTECTED] wrote:
By the way - any update on the optional validator stuff together with
I don't know, but I suspect it'd break the TCK. 1.2 corrected the
1.1 design flaw, so I'm guessing it's required in 1.1.
On 2/8/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Does it require API changes or would it break the TCK if we would go
1.2 compatible here?
regards,
Martin
On
-
From: Mike Kienenberger [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 08, 2006 7:02 PM
To: MyFaces Development; [EMAIL PROTECTED]
Subject: status of the optional validator stuff [Was:
Bookmarking, History and JSF]
On 1/31/06, Martin Marinschek [EMAIL PROTECTED] wrote:
By the way
To: MyFaces Development; [EMAIL PROTECTED]
Subject: status of the optional validator stuff [Was:
Bookmarking, History and JSF]
On 1/31/06, Martin Marinschek [EMAIL PROTECTED] wrote:
By the way - any update on the optional validator stuff
together with
partial validation? Ok, maybe we
-- Forwarded message --
From: Martin Marinschek [EMAIL PROTECTED]
Date: Feb 8, 2006 11:07 PM
Subject: Re: status of the optional validator stuff [Was: Bookmarking,
History and JSF]
To: Mike Kienenberger [EMAIL PROTECTED]
You're sure there are any API changes?
If there aren't, we
-Original Message-
From: Martin Marinschek [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 08, 2006 11:08 PM
To: MyFaces Development
Subject: Fwd: status of the optional validator stuff [Was:
Bookmarking, History and JSF]
-- Forwarded message --
From: Martin
I wonder where that is.
If I look into UIInput, it calls in restoreState/saveState
saveAttachedState on the validators.
Now that should save and restore the state of the validators, right?
Maybe there's something in the tag which kills them again.
regards,
Martin
On 2/8/06, Mike
Hi!
In proposal 2 (see above) the use-data _and_ the structure is
transferred to the client, so by changing the structure, the (hacking)
user can try to recreate and set any properties on any bean on the
server, if no encryption is used.
Regardless of the solution we use, we should
Regardless of the solution we use, we should abstract the creation of
the url so one can replace it with its own implementation.
+1 an abstract *layer* sounds good
+1 for tinyurl like urls!
-Matthias
I see three types of them:
*) plain - pass through (so hackable)
*) encryption (leads to
Yeah - but where do you store these tinyurls? On the server? In a database?
+1 for making it configurable, -1 for making it the default ;)
regards,
Martin
On 1/31/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Regardless of the solution we use, we should abstract the creation of
the url
Martin Marinschek schrieb:
Yeah - but where do you store these tinyurls? On the server? In a database?
Yes, in an database.
+1 for making it configurable, -1 for making it the default ;)
+1 - thats exactly what I thought!
Ciao,
Mario
-Original Message-
From: Martin Marinschek [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 31, 2006 11:58 AM
To: MyFaces Development
Subject: Re: Bookmarking, History and JSF
Yeah - but where do you store these tinyurls? On the server?
In a database?
Offer an interface
Ok, I've discussed with Manfred and Thomas some more, and our personal
preference would be proposal 2 with (optional) encryption (or
signature, just so that the user can't temper with the URL).
regards,
Martin
On 1/31/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
Martin Marinschek schrieb:
21) [EMAIL PROTECTED] wrote:
-Original Message-
From: Martin Marinschek [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 31, 2006 11:58 AM
To: MyFaces Development
Subject: Re: Bookmarking, History and JSF
Yeah - but where do you store these tinyurls? On the server
-Original Message-
From: Martin Marinschek [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 31, 2006 12:04 PM
To: MyFaces Development
Subject: Re: Bookmarking, History and JSF
Ok, I've discussed with Manfred and Thomas some more, and our personal
preference would be proposal 2
Hi John,
ok - so you agree with me that the renderer has to take care of that?
Cause I still don't get that getURL stuff from the navigation-handler
- It would be great if you could elaborate on that.
as for saving parameters, I see three approaches cristalizing out now:
1) configure in the
As for the security of proposal
2)
if we do client-side state-saving, we do encryption, right? Would we
have to do encryption here, too, to make this more secure?
Would that run against the notion of readable, nice bookmarks? Probably yes...
regards,
Martin
On 1/30/06, Martin Marinschek
Maybe I'm missing something, but I don't understand why state saving and bookmarking are related.Isn't a bookmark something you would potentially paste into an email and send to your friend? There doesn't seem to be any assosicated state present in the URL or on the server, so why do we need
Considering the huge number of responses in this thread, this is
obviously a big problem. While there were good suggestions on how to
improve the situation, with all of them, we are only making (better)
alternatives to the broken base functionality. And yes, some say it's
not really broken because
Well, for your suggestion, no state saving is necessary, right.
you'll only have use-data transferred via the wire to the client, so
that's somewhat ok.
In proposal 2 (see above) the use-data _and_ the structure is
transferred to the client, so by changing the structure, the (hacking)
user can
Yeah, Kalle, you're absolutely right. I was thinking about that too -
if you have a fixed action-parameter or add a defaultAction
parameter to a link, you can already render the new view-id instead of
the old one.
But: you'll have to make sure that the postback somehow includes the
information on
hmm
I don't get it - you usually don't save stuff like id's in the
component tree, so how would it help you to apply an id to an item in
the component tree?
Or did I get you wrong here?
regards,
Martin
On 1/29/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
- If the bean is
Hi!
I don't get it - you usually don't save stuff like id's in the
component tree, so how would it help you to apply an id to an item in
the component tree?
No id?
I talked about the same id (client-id) you use to pass the request POST
parameters into the view.
So I don't talk about
Ok, I see...
hmm, we'll have to think about that.
regards,
Martin
On 1/29/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
I don't get it - you usually don't save stuff like id's in the
component tree, so how would it help you to apply an id to an item in
the component tree?
No id?
What Mario is suggesting is the foundation for my stateless JSF solution. It
doesn't make sense to duplicate the cabilities of a component framework and jam
it into a struts/webwork solution-- around validation, parameter handling, and
action invocation.
Your JSF document, with all of its
You're a philosoph, Jacob ;)
So how do we go about saving partial-state?
regards,
Martin
On 1/29/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
What Mario is suggesting is the foundation for my stateless JSF solution. It
doesn't make sense to duplicate the cabilities of a component
Thanks Adam! ;-)
I've been thinking about this a bit more recently.
One of the JSF's strengths is it's clean separation between
agent-specific details in the renderers, and it's more general
component and event model abstraction that can easily be leveraged by
application developers.
In the case
On 1/27/06, Gary VanMatre [EMAIL PROTECTED] wrote:
Hi Gary,
The basic idea creates a convention in the url for invoking the method.
contextroot/dynamic/remoting$business/cityAndStateForZip.faces?zip=80124
Right it's all about naming conventions :-)
I looked a Business.java's
Hi Matze,
that looks real nice...
I think in the end, we'll additionally have some form of url-rewrite
in place to be able to specify the stuff without parameters, but just
appending one directory after the other.
Now, I didn't quite get the story with the bookmarkable URL which is
sent by the
Hi
Now the phase listener has the convention, that foo and bar are
the bean properties
and populates the bean with the given values.
I tried to follow the thread in full, but sometimes I dont get the point
of ones objection.
Sorry, if this has already been discussed, but:
Why cant we use
Craig,
Well, I definitely agree that any sort of auto-population is very, very
worrisome. But, using value#{param.foo}/value for a managed
property still leaves behind some major problems:
- If the bean is request-scoped, it forces you to get this parameter
into every request - a major
Hi!
- If the bean is request-scoped, it forces you to get this parameter
into every request - a major challenge for postback in JSF.
Ok, this is really a problem when using param.name
- You have to very carefully check incoming parameter values
for legitimacy (in a way that JSF
Hi all,
I'm having ideas again. Must come from too much work with JSF ;)
My idea:
Bookmarking is a problem with JSF, right? Except you use h:outputLink,
but then there's this slight problem with not being in the action
system anymore ;)
Now, what do I want to be able to see in my history or to
to put it in a nutshell:
add GET-processing to JSF...
+100 ;-)
regards
Alexander
-Original Message-
From: Martin Marinschek [mailto:[EMAIL PROTECTED]
Sent: Friday, January 27, 2006 10:35 AM
To: MyFaces Development
Subject: Bookmarking, History and JSF
Hi all,
I'm having ideas again
-processing to JSF...
+100 ;-)
regards
Alexander
-Original Message-
From: Martin Marinschek [mailto:[EMAIL PROTECTED]
Sent: Friday, January 27, 2006 10:35 AM
To: MyFaces Development
Subject: Bookmarking, History and JSF
Hi all,
I'm having ideas again. Must come from too much work
+1000 for a get
Martin Marinschek schrieb:
Hi all,
I'm having ideas again. Must come from too much work with JSF ;)
My idea:
Bookmarking is a problem with JSF, right? Except you use h:outputLink,
but then there's this slight problem with not being in the action
system anymore ;)
Hi!
JSF - minus complete state-saving + GET-processing + binding into the
Navigation-framework of JSF
And then ALLOW_JAVASCRIPT=false will start working again too?
Ciao,
Mario
let's hope it will... THAT WOULD BE HYPER-GREAT ;-)
-Original Message-
From: Mario Ivankovits [mailto:[EMAIL PROTECTED]
Sent: Friday, January 27, 2006 10:58 AM
To: MyFaces Development
Subject: Re: Bookmarking, History and JSF
Hi!
JSF - minus complete state-saving + GET-processing
To: MyFaces Development
Subject: Re: Bookmarking, History and JSF
Hi!
JSF - minus complete state-saving + GET-processing + binding into the
Navigation-framework of JSF
And then ALLOW_JAVASCRIPT=false will start working again too?
Ciao,
Mario
--
http://www.irian.at
Your JSF powerhouse -
JSF
, in order to give the search engine robots a path to follow.
Excellent idea!
-Original Message-
From: Mario Ivankovits [mailto:[EMAIL PROTECTED]
Sent: 27 January 2006 09:58
To: MyFaces Development
Subject: Re: Bookmarking, History and JSF
Hi!
JSF - minus complete state-saving + GET
Hi
Now, what do I want to be able to see in my history or to bookmark? I
want to bookmark simple pages, where state is not so important at all.
Or only a small portion of the state is important...
Those simple pages I usually refer to with an action attribute that
is put (as a string)
Here goes the link for that servlet
http://tinyurl.com/8dv43
inside of invokeApplication() you could do some stuff w/ ValueBindings
to populate your bean.
-Matthias
On 1/27/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi
Now, what do I want to be able to see in my history or to
@Manfred: I guess I saw a ticket in RI stuff for this. What's the EGs
plan for enabling bookmarkable URLs ?
We could discuss it with Ed Burns this evening in the ##jsf chat.
Lately he's online almost every day...
regards
Alexander
Matthias Wessendorf schrieb:
Why not rendering a link to a NonFacesRequestServlet ?
(like the tobago stuff)
Servlet = bad idea needs an additional entry in the web.xml
(and just check how many problems the tomahawk extension filter
already causes)
The obvious place probably would be the
Servlet = bad idea needs an additional entry in the web.xml
(and just check how many problems the tomahawk extension filter
already causes)
The obvious place probably would be the extension filter (which has to
be there anyway)
or a phase listener - which would be even better because that
We could discuss it with Ed Burns this evening in the ##jsf chat.
Lately he's online almost every day...
I am not using irc, but maybe I'll install a client. but today (at
evening I am traveling)
But you could bring out this topic, right ?
-Matthias
We could optionally do that - don't know if that is practical.
I've discussed with Manfred some more, and he suggests to do the following:
give t:saveState an optional bookmarkable=true attribute, and with
that decide on some of the state to be saved even though the
tree-state is lost.
we could
Yes, sounds good.
I'm not online this evening, either, but if Jesse can hook-up with Ed
on this topic, that would be great.
regards,
Martin
On 1/27/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
We could discuss it with Ed Burns this evening in the ##jsf chat.
Lately he's online almost
-Original Message-
From: Matthias Wessendorf [mailto:[EMAIL PROTECTED]
Sent: Friday, January 27, 2006 12:09 PM
To: MyFaces Development
Subject: Re: Bookmarking, History and JSF
We could discuss it with Ed Burns this evening in the ##jsf chat.
Lately he's online almost every day
Just got to make sure i understand the issue completely.
It seems that manolito has connected a few times lately as well...
manolito == el manfredo ;)
BTW: I have a deputy bot running, which gives html-access to IRC
even when the corporate firewalls are not liking that ;-)
regards
GET-processing to JSF...
+100 ;-)
regards
Alexander
-Original Message-
From: Martin Marinschek [mailto:[EMAIL PROTECTED]
Sent: Friday, January 27, 2006 10:35 AM
To: MyFaces Development
Subject: Bookmarking, History and JSF
Hi all,
I'm having ideas again. Must come from too much work
-Original Message-
From: Alexander Smirnov [mailto:[EMAIL PROTECTED]
Sent: 27 January 2006 12:16
To: MyFaces Development
Subject: Re: Bookmarking, History and JSF
Due to navigation caases, you page after GET request may be different
from request to request, depend on application state
will
be listed in the HTML, and will therefore be followed by search engine robots.
Regards
Jamie
-Original Message-
From: Alexander Smirnov [mailto:[EMAIL PROTECTED]
Sent: 27 January 2006 12:16
To: MyFaces Development
Subject: Re: Bookmarking, History and JSF
Due to navigation
Message-
From: Martin Marinschek [mailto:[EMAIL PROTECTED]
Sent: Friday, January 27, 2006 10:35 AM
To: MyFaces Development
Subject: Bookmarking, History and JSF
Hi all,
I'm having ideas again. Must come from too much work with JSF ;)
My idea:
Bookmarking is a problem
@Manfred: I guess I saw a ticket in RI stuff for this. What's the EGs
plan for enabling bookmarkable URLs ?
Somebody can check for the id (url) of this ticket (being in a workshop
I have limited online-possibilities ;-)
regards
Alexander
Gruß Gott,
On Fri, 27 Jan 2006 10:43:23 +0100, Werner Punz [EMAIL PROTECTED] said:
WP +1000 for a get
WP Martin Marinschek schrieb:
MM I'm having ideas again. Must come from too much work with JSF ;)
MM
MM My idea:
MM
MM Bookmarking is a problem with JSF, right? Except you use
As Ed noted, saving everything into the GET request does not work
because of URL size limitations. Old stagers within the MyFaces
community might remember the so called minimizing state feature in
early MyFaces 0.x versions. The goal was to provide a JSF
implementation that works without
If you want to go minimal/stateless with JSF, it's somewhat do-able. I was
able to take a sandbox of Facelets and simply:
1) Always write an empty hidden input param for 'javax.faces.ViewState' to get
the succeeding request to expect a Restored View
2) Within ViewHandler.restoreView(..) call
I don't think the problem should be solved.
No one says that all of your commandLinks need to invoke actions-- you can
render normal links. With invoking actions, you posting transitional behavior,
with gets, there is not transitional behavior to retain. When you want to
bookmark things,
From: Matthias Wessendorf [EMAIL PROTECTED] HiNow, what do I want to be able to see in my history or to bookmark? I want to bookmark simple pages, where state is not so important at all. Or only a small portion of the state is important...Those simple pages I usually refer to with an
Well,
I think you have to distinct clearly here. The concept of actions
which lead to somewhere else is a somewhat widely used concept in
web-applications. If you don't call dynamic method-bindings, but you
have static action-references, I don't think that you can lump
together calling actions
Hi Jacob,
yes, but I'm talking about being able to pass _some_ state here. So
you don't go fully stateless, you have the ability to reduce the state
to a size where it is usable with GET-Requests.
And I want to use MyFaces t:saveState feature for providing this
ability. Together with an error to
Hallo Manolito,
Wie geht es in Wien?
On Fri, 27 Jan 2006 16:06:26 +0100, Manfred Geiler [EMAIL PROTECTED]
said:
MG As Ed noted, saving everything into the GET request does not work
MG because of URL size limitations. Old stagers within the MyFaces
MG community might remember the so called
Hi Ed,
danke, in Wien geht's hervorragend ;)
you're right, of course. This has to be clearly documented. And
indeed, this problem is unsolvable. Manfred has invested a lot of work
into MyFaces trying to get this to run somehow by further minimizing
the state - but with the restrictions imposed
Yeah, that's correct, who says ViewState actually has to be your component
model? :-)
I've thought about progressing the stateless JSF solution to instead just write
Seam's converstation ID as the ViewState (a numeric long) to match up to model
state. This kind of solution makes a lot more
Martin Marinschek schrieb:
We could optionally do that - don't know if that is practical.
I've discussed with Manfred some more, and he suggests to do the following:
give t:saveState an optional bookmarkable=true attribute, and with
that decide on some of the state to be saved even though the
From: Martin Marinschek [EMAIL PROTECTED] Hi Jacob, yes, but I'm talking about being able to pass _some_ state here. So you don't go fully stateless, you have the ability to reduce the state to a size where it is usable with GET-Requests.
I agreewith youMartin. Why not burn\generate a
How do you explain the user that he's using actions all over the
application, and then for his GET needs, he has to provide an url with
parameters and other stuff?
I don't think it's confusing at all. If anything, I would suggest something
like Craig has been bringing up where the requested URI
Hi Jacob,
Seam's state-saving method is server-side, right? The conversation
will be stored on the server? Is that a persistent storage - in the
sense of a database, or a volatile storage - in the sense of a server
session (ok, I know, server side sessions can be persisted, too;) ?
option 1) So
Hi Werner,
You're absolutely right. My could actually meant we must ;)
What we could/ do though would be to automatically fail-over to
normal state-saving and rendering, if the state grows too large. So we
have an error, right, but the app doesn't stop working. The page just
isn't bookmarkable
My idea's always been something like an optional
NavigationHandler interface:
public interface BookmarkableNavigationHandler
{
/**
* Return an URL if the MethodExpression can be handled purely
* as a GET request, or null if it cannot be done.
*/
public String getUrl(FacesContext,
BTW, a credit-where-it's-due: I should be clear that my idea's
always been... completely omits that this idea is very much
due to John Fallows!
-- Adam
On 1/27/06, Adam Winer [EMAIL PROTECTED] wrote:
My idea's always been something like an optional
NavigationHandler interface:
public
That's an interesting solution-- with webwork, it allows EL (OGNL) evaluation
of URIs, so across the board, we could do something like:
navigation-rule
from-view-id/foo.jsp/from-view-id
navigation-case
from-outcomesuccess/from-outcome
redirect/
On 1/27/06, Martin Marinschek [EMAIL PROTECTED] wrote:
outputLink doesn't tie into the action-framework - that's why...what's Struts-Shale doing here? outputLink with defaultAction=something?If you use view controllers in Shale, a GET request will trigger init(), then prerender(), then render your
That only gets you about a third of the way there, since JSF
isn't giving you a decent semantic way to generate meaningful
GET requests in the first place.
-- Adam
On 1/27/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 1/27/06, Martin Marinschek [EMAIL PROTECTED] wrote:
outputLink doesn't
And once you'd solved this what you'd *really* want on top of this is
something in the nav handler that lets you then also deal with the
incoming id query attribute that feeds naturally back into JSF component
state land instead of forcing you to hardcode logic to implement this.
(Seam
Yes, I reaaalllyyy want that as well.
Matze has already suggested that - we'll have that in our solution ;)
regards,
Martin
On 1/27/06, Adam Winer [EMAIL PROTECTED] wrote:
And once you'd solved this what you'd *really* want on top of this is
something in the nav handler that lets you then
Unless I misunderstood--
I've been saying you wouldn't want this though, because now your logic is bound
to some assumption of previous state-- where did the id come from, which is bad
for GETs.
You could pass the id, using EL evaluation of to-view-id, allowing a (separate)
view decide how
Martin Marinschek wrote:
outputLink doesn't tie into the action-framework - that's why...
what's Struts-Shale doing here? outputLink with defaultAction=something?
regards,
Martin
In struts, I can perform action for request on any ...do link not only
for submitting form, but for ANY
JSF doesn't have a built-in front controller. If anything, it should be
optional, but things like no DB connection are usually handled by global
filters/policies and wouldn't be on a per-action basis.
The additional lifecycle events that Shale introduces will also be available in
JSF 1.2 with
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, January 27, 2006 7:19 PM
To: dev@myfaces.apache.org; dev@myfaces.apache.org
Subject: Re: Bookmarking, History and JSF
Unless I misunderstood--
I've been saying you wouldn't want this though
82 matches
Mail list logo
