You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Markus Wiederkehr <as...@fantasymail.de> on 2004/09/02 10:55:22 UTC
contrib:Table source parameter
I experimented with a Table and discovered the following problem: When I
use the 'source' parameter the corresponding getter is invoked twice per
request when you change the sort order or navigate to another page of
the table.
Is this a bug or a feature? I think it might be a bug because fetching
the data from the database is usually a costly operation.
Here's my example code (Tapestry 3.0):
<table jwcid="table@contrib:Table" source="ognl:locales"
columns="Locale:toString(), Language, Country, Variant"/>
public class Table extends BasePage
{
public Locale[] getLocales()
{
System.out.println("getLocales()");
return Locale.getAvailableLocales();
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: contrib:Table source parameter
Posted by je...@nordija.com.
> I experimented with a Table and discovered the following problem: When I
> use the 'source' parameter the corresponding getter is invoked twice per
> request when you change the sort order or navigate to another page of
> the table.
Do yuo mean that after you try to change the sort order, the getter is
invoked again?
If so, it is a 2feature". The component is rendered again to recreate the
state on the server. The same happens for your own pages. They rewind to
crete the state. The check cycle.isRewinding() can be used to prevent this
if you don´t want that to happen.
Don´t know if that can help you.
>
> Is this a bug or a feature? I think it might be a bug because fetching
> the data from the database is usually a costly operation.
>
> Here's my example code (Tapestry 3.0):
>
> <table jwcid="table@contrib:Table" source="ognl:locales"
> columns="Locale:toString(), Language, Country, Variant"/>
>
> public class Table extends BasePage
> {
> public Locale[] getLocales()
> {
> System.out.println("getLocales()");
> return Locale.getAvailableLocales();
> }
> }
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
/Jacob
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Getting localized properties of a component without the component [auf
Viren geprueft]
Posted by Jonathan O'Connor <Jo...@xcom.de>.
Folks, I have come up with a snazzy (can't say "groovy" any more :-) way
of turning Exceptions into nice localized formatted messages.
What I do is make a message key from the Exception class name, and then
look this up in the current page's properties. However, I would like to
have a default set of properties, which are kept with a component.
However, the DefaultComponentMessagesSource insists on having an actual
component to query.
In getLocalizedProperties(IComponent component) it calls
component.getSpecification().getSpecificationLocation(), and
component.getPage().getLocale().
After that the code only uses this IResourceLocation and Locale.
Would anyone mind if I extracted that code, and made it public.
Howard's earlier message on getting the page specification means I can
easily get the specification location too.
IEngine engine = cycle.getEngine();
ISpecificationSource source = engine.getSpecificationSource();
INamespace namespace = source.getApplicationNamespace();
IComponentSpecification pageSpec =
namespace.getPageSpecification("Foo");
Of course, any better solutions will be eagerly read.
Ciao,
Jonathan O'Connor
XCOM Dublin