tapestry-user@jakarta.apache.org
[Top] [All Lists]

Re: Best Practice: Controlling Page Names

Subject: Re: Best Practice: Controlling Page Names
From: "Pedro Viegas"
Date: Wed, 29 Mar 2006 00:00:15 +0100
Thank you all.
I also beleave, Adam, that the static imported page names class may be the
best solution so far.
I'm also very uncertain of the best method and will "try this on for size".
The page names class has also one other advantage. With this kind of
centralization of pages, one has a central point with knowladge of all pages
in the application witch one can extend when a page flow control is
required.
For say dinamic menu rendering, site maps, bread-crumbs, and so on...
I'll explore this idea a bit more...

Thanks again for your inputs.

On 3/28/06, Adam Zimowski <zimowski74@xxxxxxxxx> wrote:
>
> Actually the work-around I use with page level constants is far from
> perfect, and I forgot to mention its biggest limitation.  It's only
> good when you assume that only one page exists per page class. My
> solution fails miserably the minute you try to have two pages using
> same page class (same java logic). What then?
>
> Also, the name of the page you pass to @InjectPage is not the same as
> name of page class. That is a very important distintion. It is the
> name of the page as you defined it in the *.application file. It often
> will be the same name as page class name, but does not have to be.
>
> In my application, for instance, each page class follows a simple
> naming convention:
>
> XXXPage
>
> for instance:
>
> HomePabe, BasicProfilePage, AboutPage, SearchPage
>
> but actual page names defined in the *.application file are:
>
> <page name="About" specification-path="pages/About.page"/>
> <page name="BasicProfile" specification-path="pages/BasicProfile.page"/>
> <page name="Browse" specification-path="pages/Browse.page"/>
> <page name="Home" specification-path="pages/Home.page"/>
>
> In this case you do:
>
> @InjectPage("Home"), @InjectPage("About"), etc...
>
> The reason my page classes have Page suffix is for clarity when
> producing a JavaDoc. It then becomes very important to follow page
> name conventions. But since often page title is name of the page, it
> doesn't make sense to have page name same as class name.
>
> Anyway, I think a better solution (which I'm about to try) is to have
> a global PageName.java with constants for each page.
>
> public class PageNames {
> public static final String PAGE_HOME = "Home";
> public static final String PAGE_ABOUT = "About";
> etc...
> // every page name should match value from <page name="..."
> }
>
> And since one of nice Java 1.5 features brings us static imports, this
> *may* be the ultimate solution.
>
> On 3/27/06, Ryan Holmes <ryan@xxxxxxxxxxxxx> wrote:
> > Eclipse will automatically update the page name string in your
> > @InjectPage annotations when you rename the page class, so it's really
> > no problem to use raw strings. You just have to check the "Update
> > textual matches in comments and strings" box.
> >
> > -Ryan
> >
> > Adam Zimowski wrote:
> >
> > >I compriomised on a page level constant. Not pretty, but a lot better
> > >than hard-coding string.
> > >
> > >public class FooPage extends BasePage {
> > >
> > >// below must match name of the page as
> > >// Tapestry sees it (not necessairly same as name of page class)
> > >public final static String NAME = "Foo";
> > >
> > >}
> > >
> > >@InjectPage(FooPage.NAME)
> > >public abstract FooPage getFooPage();
> > >
> > >It's not ideal, but it works. If I change my page name, I only have to
> > >remember to update constant in page class, and Inject annotations get
> > >refactored automatically. If you or anyone else thinks of anything
> > >better, I'm all for it...
> > >
> > >Adam
> > >
> > >On 3/27/06, Pedro Viegas <pviegas@xxxxxxxxx> wrote:
> > >
> > >
> > >>Anyone found a way to make this happen?
> > >>Seems like a very important point. Refactoring happends all the time.
> Is
> > >>everyone using these string constants all over the place or not simply
> using
> > >>the InjectPage?
> > >>
> > >>On 3/6/06, Adam Zimowski <zimowski74@xxxxxxxxx> wrote:
> > >>
> > >>
> > >>>Thanks much, Till.   I'm on JDK 1.5 and tried
> > >>>MyPage.class.getSimpleName() but compiler is smart enough to figure
> > >>>out this is a non constant expression and won't let you inject page:
> > >>>
> > >>>@InjectPage(MyPage.class.getSimpleName())
> > >>>
> > >>>:-(
> > >>>
> > >>>On 3/6/06, Till Nagel <tn@xxxxxxx> wrote:
> > >>>
> > >>>
> > >>>>Adam,
> > >>>>
> > >>>>to avoid repeating the page name as string constant, you could use
> > >>>>
> > >>>>public static final String NAME =
> > >>>>MyPage.class.getName().replaceAll(".*\\.", "");
> > >>>>
> > >>>>or, if you are using Java 1.5
> > >>>>
> > >>>>public static final String NAME = MyPage.class.getSimpleName();
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>-----Original Message-----
> > >>>>>From: Adam Zimowski [mailto:zimowski74@xxxxxxxxx]
> > >>>>>Sent: Friday, March 03, 2006 9:04 PM
> > >>>>>To: Tapestry users
> > >>>>>Subject: Re: Best Practice: Controlling Page Names
> > >>>>>
> > >>>>>Enums wouldn't work because .toString() would result in a
> non-constant
> > >>>>>expression.
> > >>>>>
> > >>>>>So let's assume every page has:
> > >>>>>
> > >>>>>public static final String NAME = "page_name as defined in
> > >>>>>
> > >>>>>
> > >>>>*.application
> > >>>>
> > >>>>
> > >>>>>file";
> > >>>>>
> > >>>>>Then:
> > >>>>>
> > >>>>>@InjectPage(Page.NAME)
> > >>>>>
> > >>>>>Is this a clean way to do this?
> > >>>>>
> > >>>>>On 3/3/06, Adam Zimowski <zimowski74@xxxxxxxxx> wrote:
> > >>>>>
> > >>>>>
> > >>>>>>I'd like to hear what you folks would recommend for controlling
> when
> > >>>>>>referring to pages via their names, such as:
> > >>>>>>
> > >>>>>>@InjectPage("Registration")
> > >>>>>>
> > >>>>>>etc..
> > >>>>>>
> > >>>>>>If I have the same page injected in 20 places, then rename the
> page
> > >>>>>>
> > >>>>>>
> > >>>>it
> > >>>>
> > >>>>
> > >>>>>>would be a pain to refactor. Since I'm on JDK 1.5, I'm thinking of
> > >>>>>>creating page enum, and since toString() of an enum is its value
> it
> > >>>>>>would work rather nicely:
> > >>>>>>
> > >>>>>>public enum EPages { Home, Registration, etc... }
> > >>>>>>
> > >>>>>>@InjectPage(EPages.Registration)
> > >>>>>>
> > >>>>>>Sure, I have one more place to maintain with page names, but I
> > >>>>>>wouldn't mind it comparing to current state of affairs.
> > >>>>>>
> > >>>>>>Or is there even a better way?  I'd like to keep injection
> > >>>>>>
> > >>>>>>
> > >>>>annotation
> > >>>>
> > >>>>
> > >>>>>>because I've come so accustomed to it.
> > >>>>>>
> > >>>>>>Regards,
> > >>>>>>Adam
> > >>>>>>
> > >>>>>>
> > >>>>>>
> >
> >>>>>---------------------------------------------------------------------
> > >>>>>To unsubscribe, e-mail:
> tapestry-user-unsubscribe@xxxxxxxxxxxxxxxxxx
> > >>>>>For additional commands, e-mail:
> tapestry-user-help@xxxxxxxxxxxxxxxxxx
> > >>>>>
> > >>>>>
> >
> >>>>---------------------------------------------------------------------
> > >>>>To unsubscribe, e-mail: tapestry-user-unsubscribe@xxxxxxxxxxxxxxxxxx
> > >>>>For additional commands, e-mail:
> tapestry-user-help@xxxxxxxxxxxxxxxxxx
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>---------------------------------------------------------------------
> > >>>To unsubscribe, e-mail: tapestry-user-unsubscribe@xxxxxxxxxxxxxxxxxx
> > >>>For additional commands, e-mail:
> tapestry-user-help@xxxxxxxxxxxxxxxxxx
> > >>>
> > >>>
> > >>>
> > >>>
> > >>--
> > >>Pedro Viegas
> > >>
> > >>
> > >>
> > >>
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: tapestry-user-unsubscribe@xxxxxxxxxxxxxxxxxx
> > >For additional commands, e-mail: tapestry-user-help@xxxxxxxxxxxxxxxxxx
> > >
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@xxxxxxxxxxxxxxxxxx
> > For additional commands, e-mail: tapestry-user-help@xxxxxxxxxxxxxxxxxx
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: tapestry-user-help@xxxxxxxxxxxxxxxxxx
>
>


--
Pedro Viegas
<Prev in Thread] Current Thread [Next in Thread>