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