impact of CLIENT_STATE_MAX_TOKENS ?
What other impact is there if a low value is set? Just cannot use the back button? We are thinking of lowering this number to shrink the httpsession size... also when does an expired token's serverside data get removed from the httpsession? is it the token expired on the client/browser and then the next hit to the server removes it from the server cache? org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS In "token"-based client-side state saving, chooses how many tokens should be preserved at any one time. The default value is 15. When this is exceeded, state will have effectively been "forgotten" for the least recently viewed pages, which can impact users that actively use the Back button or that have multiple windows open simultaneously. Developers building HTML applications that rely heavily on frames will likely need to increase this value.
pluggable cache implementation / store
Any plans for a pluggable cache store? For example putting the application cache or root cache in jcscache instead of the httpsession and making this configurable? Thanks!
Application View Cache : page-by-page enablement
>From the website: http://myfaces.apache.org/trinidad/devguide/configuration.html At the moment, the Application View Cache can only be enabled or disabled globally. We are considering adding support for disabling (or enabling) the view cache on a page-by-page basis. What is the status of this? Target release? pro/con? Thanks!
Re: [Facelets] Logging and Facelets
Am Samstag, 20. Oktober 2007 00:11:32 schrieb Chris Pratt: > My main application uses Log4j and most everything else either uses > Common's Logging or SLF4J, both of which are being used as fronts for > Log4j. The only exception is Facelets (at least according to their > documentation). Is there any way to get Facelets to play nice with > all the other packages and write out the logs along with every other > package I'm using? Thanks. > (*Chris*) You should forward this to the Facelets Mailinglist. Regards, Timm
Re: [trinidad] what is the proper lifecycle phase for populating a
Seam's injection with factory support would work for you I would believe.
@Name("doesntMatter")
public class Whatever {
@In(required=false) @Out(required=false)
private DataModel mymodel;
@Factory("mymodel")
public DataModel createModel() {
... load the model here
}
// for programmatic access:
public DataModel getDataModel() {
if (mymodel == null) {
mymodel = createModel();
}
return mymodel;
}
}
This would force #{mymodel} to be lazy loaded as needed and backing
beans could use "getDataModel"
You could then also have a on-load function to load this data too if you want.
-Andrew
On 10/20/07, Martin Ahrer <[EMAIL PROTECTED]> wrote:
>
> I'm already using request scope to keep the managed bean qbeController (this
> is the one providing the DataModel) so that data is refreshed every time the
> page is refreshed.
>
> With using the JSF 1.2 beforePhase and afterPhase method bindings
> I already try to load data at a very specific phase. I know about jsf-comp,
> shale (does not work with JSF 1.2) and seam, this is almost the same
> solution just different tags or annotations to control the phase and when to
> invoke a specific method. I don't think they would do the trick here!
> Correct me if I should be wrong!
>
> May be I did not state it clearly enough, the problems that I'm fighting are
> a result from restricting data loading to a specific phase. Especially
> delaying data loading to before RENDER_RESPONSE causes the Trinidad table
> not to allow me to click a row and perform a selection method. It simply
> would not create a request! I don't know if this is a Trinidad problem or if
> this is a general issue that results from the JSF life-cycle. As I move data
> loading to the earlier APPLY_REQUEST_VALUES phase the Trinidad table works
> BUT data loading can't be performed properly because the backing bean has
> not yet been refreshed with the query criteria form input :(
>
>
>
> Andrew Robinson-5 wrote:
> >
> > Typically, what I have seen is to store the data in a request scoped
> > member variable. This is used with "if not loaded, load, otherwise use
> > current instance" paradigm.
> >
> > There are 3 libraries that I am aware of that also provide on-load
> > functionality, so that you can load the data before rendering (thus
> > making error handling easier):
> >
> > * jsf-comp on-load
> > * Seam
> > * Shale
> >
> > The simplest way is to store you model directly on the request context
> > from the external request.
> >
> > -Andrew
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/-trinidad--what-is-the-proper-lifecycle-phase-for-populating-a-%3Ctr%3Atable%3E-tf4654950.html#a13308254
> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>
>
Re: [Trinidad 1.0.3] returnListener is broken
On 10/17/07, max.starets <[EMAIL PROTECTED]> wrote: > > Thanks, Adam. > > I like your suggestion. The only exception I see is that we would still > establish currency for selection events. Agreed? Wouldn't that still mean that if you launch a dialog during a selection event, the return will fail?. Or that PPR'ing a facet of the table in response to a selection event will likely fail? I'm wondering if we want something much uglier here: a way to still establish currency (and do it for all events), but without mucking with client IDs. -- Adam > > I will submit a new patch for review. Sorry for introducing the bug in a > first place. > > Max > > > > Adam Winer wrote: > > > > > > The fix, I think, is to not set the currency, but instead merely > > set up the EL state as if currency were set, e.g. going from > > - set row key to first selected row > > - process the event > > - restore row key > > > > ... to the more verbose: > > > > - get original values "var" and "varStatus" off the request map > > - set row key to first selected row > > - grab new "var" and "varStatus" off the request map > > - restore row key > > - set new "var" and "varStatus" onto the request map > > - process the event > > - restore "var" and "varStatus" to original values > > > > For now, you can work around this (significant) bug by > > moving the panelButtonBar to after the table, and > > out of the "footer". But we should roll a 1.0.4 fairly > > soon to fix this regression, and any others if they get > > found soon. > > > > > > > > -- > View this message in context: > http://www.nabble.com/-Trinidad-1.0.3--returnListener-is-broken-tf4594019.html#a13254310 > Sent from the MyFaces - Users mailing list archive at Nabble.com. > >
Re: [Trinidad] org.apache.myfaces.trinidadinternal.io.DebugResponseWriter _logDuplicateId
On 10/19/07, Martin Ahrer <[EMAIL PROTECTED]> wrote:
>
> Trinidad is warning about duplicate id attributes even though I do NOT have
> used duplicate ids. So, I'm concerned if something can be done to avoid them
> or at least I'd like to know if any troubles can result from them?
Both of these cases are coming from not recognizing that tr:inputText
has built-in label and message support unless you set simple="true".
> In this special case I was able to produced these warning either this way
>
>
> value="#{queryByExampleController.example.type}"/>
>
This should generally just be:
>
> -->>
> 19.10.2007 16:27:43
> org.apache.myfaces.trinidadinternal.io.DebugResponseWriter _logDuplicateId
> WARNUNG: The id "typeInput::icon" is used more than once.
> 19.10.2007 16:27:43
> org.apache.myfaces.trinidadinternal.io.DebugResponseWriter _logDuplicateId
> WARNUNG: The id "typeInput::msg" is used more than once.
>
> or even here
>
>
... and here, the tr:message is unnecessary (unless you set
simple="true" on the inputText).
-- Adam
>
> -->>
>
> 19.10.2007 16:27:43
> org.apache.myfaces.trinidadinternal.io.DebugResponseWriter _logDuplicateId
> WARNUNG: The id "typexxx::msg" is used more than once.
>
> with the later case the warning disappears as the is removed!
> --
> View this message in context:
> http://www.nabble.com/-Trinidad--org.apache.myfaces.trinidadinternal.io.DebugResponseWriter-_logDuplicateId-tf4653676.html#a13295836
> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>
>
Re: [trinidad] what is the proper lifecycle phase for populating a
I'm already using request scope to keep the managed bean qbeController (this is the one providing the DataModel) so that data is refreshed every time the page is refreshed. With using the JSF 1.2 beforePhase and afterPhase method bindings I already try to load data at a very specific phase. I know about jsf-comp, shale (does not work with JSF 1.2) and seam, this is almost the same solution just different tags or annotations to control the phase and when to invoke a specific method. I don't think they would do the trick here! Correct me if I should be wrong! May be I did not state it clearly enough, the problems that I'm fighting are a result from restricting data loading to a specific phase. Especially delaying data loading to before RENDER_RESPONSE causes the Trinidad table not to allow me to click a row and perform a selection method. It simply would not create a request! I don't know if this is a Trinidad problem or if this is a general issue that results from the JSF life-cycle. As I move data loading to the earlier APPLY_REQUEST_VALUES phase the Trinidad table works BUT data loading can't be performed properly because the backing bean has not yet been refreshed with the query criteria form input :( Andrew Robinson-5 wrote: > > Typically, what I have seen is to store the data in a request scoped > member variable. This is used with "if not loaded, load, otherwise use > current instance" paradigm. > > There are 3 libraries that I am aware of that also provide on-load > functionality, so that you can load the data before rendering (thus > making error handling easier): > > * jsf-comp on-load > * Seam > * Shale > > The simplest way is to store you model directly on the request context > from the external request. > > -Andrew > > > -- View this message in context: http://www.nabble.com/-trinidad--what-is-the-proper-lifecycle-phase-for-populating-a-%3Ctr%3Atable%3E-tf4654950.html#a13308254 Sent from the MyFaces - Users mailing list archive at Nabble.com.
