Return-Path: 
 <tapestry-dev-return-5591-apmail-jakarta-tapestry-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-tapestry-dev-archive@www.apache.org
Received: (qmail 62743 invoked from network); 30 Mar 2005 16:32:57 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 30 Mar 2005 16:32:57 -0000
Received: (qmail 78838 invoked by uid 500); 30 Mar 2005 16:32:55 -0000
Delivered-To: apmail-jakarta-tapestry-dev-archive@jakarta.apache.org
Received: (qmail 78820 invoked by uid 500); 30 Mar 2005 16:32:55 -0000
Mailing-List: contact tapestry-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:tapestry-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:tapestry-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:tapestry-dev-help@jakarta.apache.org>
List-Post: <mailto:tapestry-dev@jakarta.apache.org>
List-Id: "Tapestry development" <tapestry-dev.jakarta.apache.org>
Reply-To: "Tapestry development" <tapestry-dev@jakarta.apache.org>
Delivered-To: mailing list tapestry-dev@jakarta.apache.org
Received: (qmail 78806 invoked by uid 99); 30 Mar 2005 16:32:55 -0000
X-ASF-Spam-Status: No, hits=0.4 required=10.0
	tests=DNS_FROM_RFC_ABUSE,RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: domain of glongman@gmail.com designates
 64.233.170.192 as permitted sender)
Received: from rproxy.gmail.com (HELO rproxy.gmail.com) (64.233.170.192)
  by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 30 Mar 2005 08:32:54 -0800
Received: by rproxy.gmail.com with SMTP id a41so146603rng
        for <tapestry-dev@jakarta.apache.org>;
 Wed, 30 Mar 2005 08:32:52 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=Xp+2zERH+6xdOaK0aXdQpiTjmoruZADSpjhbeuYu8eysQ6NO5ho30YVMn5e3Zyod80blyYGEZd7nhJFZ0FKEkVIMm/TYi2dffi3GQhTEUt5suy1r7/gKIWzNr44fxqyUao4D4yjcRvittEJzU1Fdg+oBHPAWG4k3tASJUnBAW9E=
Received: by 10.38.13.39 with SMTP id 39mr620263rnm;
        Wed, 30 Mar 2005 08:32:51 -0800 (PST)
Received: by 10.38.24.48 with HTTP; Wed, 30 Mar 2005 08:32:50 -0800 (PST)
Message-ID: <94b38848050330083278c3a575@mail.gmail.com>
Date: Wed, 30 Mar 2005 11:32:50 -0500
From: Geoff Longman <glongman@gmail.com>
Reply-To: Geoff Longman <glongman@gmail.com>
To: Tapestry development <tapestry-dev@jakarta.apache.org>
Subject: Re: Spindle & Tap 3.1 - pointed questions
In-Reply-To: <ecd0e33105033007217d0cdb72@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
References: <94b3884805032907182773f2f6@mail.gmail.com>
	 <ecd0e33105032909272f774923@mail.gmail.com>
	 <94b388480503291015f5f9def@mail.gmail.com>
	 <ecd0e33105032910302effc2fa@mail.gmail.com>
	 <94b38848050329112727eeec81@mail.gmail.com>
	 <ecd0e33105032912414fa5881b@mail.gmail.com>
	 <94b38848050329163865c448a9@mail.gmail.com>
	 <94b388480503300712602deea0@mail.gmail.com>
	 <ecd0e33105033007217d0cdb72@mail.gmail.com>
X-Virus-Checked: Checked
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Oops, my last was intended for the list.

I'm trying to get my head around:
http://wiki.apache.org/jakarta-tapestry/Tapestry31

"Update: This has started, and page names can now have one or more
folder names, i.e., admin/threads/ThreadAdmin. This would locate a
page specification as /WEB-INF/admin/threads/ThreadAdmin.page and an
HTML template in the same folder, or as
/admin/threads/ThreadAdmin.html. The Shell component now renders a
<base> tag."

If the page name will now carry around the extra path information I
see how this would work. But, the PageSpecificationResolver's lookup
algorithm remains (as yet?) unchanged from 3.0 and according to that
code the statement "This would locate a page specification as
/WEB-INF/admin/threads/ThreadAdmin.page " is incomplete.

For a page called "admin/Menu" the lookup would proceed (for app namespace):

1. as defined in .application - how does that work with a <page> tag
that allows extra path info in the name attr but still (according to
Tap 3.1 DTD) requires a specification-path?
i.e. <page name="admin/Menu" specification-path="app/extra/Menu.page"/>

Ah, I think I understand. In this case Tapestry uses the path to
locate the spec and if it's template is no co-located it uses the path
info in the name to check if the template exists relative to the
context root. no?


2. context/WEB-INF/path to .application/admin/Menu.page
3. context/WEB-INF/servlet-name/admin/Menu.page
4. context/WEB-INF/admin/Menu.page
5. context/admin/Menu.html
(omitting the spec resolver delegate option).

--------
All this extra-path-info-in-the-name guff does *not* apply to components, right?

And, what happens when a user does this? 

page="myLib:stuff/Menu"?
-------

It's all becoming clear as mud.

Geoff

On Wed, 30 Mar 2005 10:21:59 -0500, Howard Lewis Ship <hlship@gmail.com> wrote:
> The page name can now inlcude the slash character, i.e., "admin/Menu";
> the folder name ("admin/") carries through during all the searches for
> specifications.
> 
> Need to update the specificaiton parser to allow slashes inside the
> <page> element.
> 
> 
> On Wed, 30 Mar 2005 10:12:06 -0500, Geoff Longman <glongman@gmail.com> wrote:
> > A new question:
> >
> > On the wiki there is the statement that pages can be referred to via
> > path relative to the context root. Where in the code is this kind of
> > lookup handled? I looked at the javadoc for
> > PageSpecificationResolverImpl and the lookup algorithm appears to be
> > unchanged from Tap 3.0
> >
> > Also, will this path quilified lookup also apply for .jwc files?
> >
> > Geoff
> >
> >
> > On Tue, 29 Mar 2005 18:38:49 -0600, Geoff Longman <glongman@gmail.com> wrote:
> > > That particular case is not a problem for me. I don't really care who
> > > contributed what prefix as long as I can validate a user string
> > > against the list.
> > >
> > > Plus, having read the Tapestry 3.1 docs and tap hivemodule stuff I can
> > > deduce that for "engine-service:X", X comes from another list and I
> > > can find that list.
> > >
> > > Geoff
> > >
> > >
> > > On Tue, 29 Mar 2005 15:41:23 -0500, Howard Lewis Ship <hlship@gmail.com> wrote:
> > > > So much of HiveMind is defined in itself, this is likely to be a
> > > > problem for tools.  For example, the list of valid prefixes is a
> > > > configuration point (hivemind.ObjectProviders) and Tapestry adds a
> > > > couple to the default list (infrastructure:, engine-service:).  It's
> > > > wheels within wheels and was not designed for tooling, alas.
> > > >
> > > >
> > > > On Tue, 29 Mar 2005 14:27:38 -0500, Geoff Longman <glongman@gmail.com > wrote:
> > > > > That would be cool!
> > > > >
> > > > >  I'd like to be able to confirm that a given service id exists:
> > > > >
> > > > > <inject property="service-ref" object="service:myModuleId.MyService"/>
> > > > >
> > > > > To be complete I would need to confirm the validity user strings
> > > > > against prefixes contributed to hivemind.ObjectProviders
> > > > >
> > > > > and I guess to be really complete if the prefix is "engine-service"
> > > > > would need to lookup the valid service names registered with
> > > > > apestry.services.ApplicationServices (is that right?)
> > > > >
> > > > > Same kinda stuff would be needed for the <inject-state> ,<set> and
> > > > > <binding> tags no?
> > > > >
> > > > > Geoff
> > > > >
> > > > >
> > > > > On Tue, 29 Mar 2005 13:30:24 -0500, Howard Lewis Ship <hlship@gmail.com > wrote:
> > > > > > Perhaps we could change HiveMind's RegistryBuilder class to have an
> > > > > > additional method that returns some intermediate object that can be
> > > > > > queried for this kind of information.
> > > > > >
> > > > > >
> > > > > > On Tue, 29 Mar 2005 13:15:10 -0500, Geoff Longman <glongman@gmail.com > wrote:
> > > > > > > > Guess I missed the prior message.  Kinda busy!
> > > > > > >
> > > > > > > Thanks for answering. Anything you (or anyone) can add will help speed
> > > > > > > things along!
> > > > > > >
> > > > > > > > >
> > > > > > > > > 1. add Hivemind binding prefix?
> > > > > > > > >
> > > > > > > > > What is this?
> > > > > > > >
> > > > > > > > There's a whole suite of new prefixes for binding, in addition to
> > > > > > > > "ognl:" and "message:".  And its extensible!
> > > > > > > >
> > > > > > > > hivemind: refers to an object defined within HiveMind, for example:
> > > > > > > >
> > > > > > > > hivemind:service:tapestry.Infrastructure
> > > > > > > >
> > > > > > > > This saves you the trouble of injecting a HiveMind object into a
> > > > > > > > property and then accessing that property via OGNL.
> > > > > > >
> > > > > > > ok, that's what I thought.  Whew it takes a lot of drilling around the
> > > > > > > code to figure out how this all works!
> > > > > > >
> > > > > > > I think that bringing Spindle up to date will be a bigger job than
> > > > > > > usual ;-). Any chance that it is possible now to build a meta hivemind
> > > > > > > registry? ie. one that doesn't try and instantiate services etc? i.e
> > > > > > > lightweight.
> > > > > > >
> > > > > > > Things that this would be useful for:
> > > > > > >
> > > > > > > ask HM does this service id exist?
> > > > > > > ask HM, for service X, what is expected iface
> > > > > > > ask HM, what are contributions to point X?
> > > > > > >
> > > > > > > The ideal solution would be to model HM as completely as Spindle does
> > > > > > > now. Would like to do that at some point (opens doors to design time
> > > > > > > validation and editors for HM!) but I think it would delay my current
> > > > > > > task too much.
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > 2. add lookup to determine page class from page name.
> > > > > > > > >
> > > > > > > > > Am I correct to assume that this feature comes into play only for
> > > > > > > > > specless pages?
> > > > > > > >
> > > > > > > > And for pages that omit the class attribute.
> > > > > > >
> > > > > > > ahh I didn't notice that the class attribute was now optional.
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Howard M. Lewis Ship
> > > > > > Independent J2EE / Open-Source Java Consultant
> > > > > > Creator, Jakarta Tapestry
> > > > > > Creator, Jakarta HiveMind
> > > > > >
> > > > > > Professional Tapestry training, mentoring, support
> > > > > > and project work.  http://howardlewisship.com
> > > > > >
> > > > >
> > > >
> > > > --
> > > > Howard M. Lewis Ship
> > > > Independent J2EE / Open-Source Java Consultant
> > > > Creator, Jakarta Tapestry
> > > > Creator, Jakarta HiveMind
> > > >
> > > > Professional Tapestry training, mentoring, support
> > > > and project work.  http://howardlewisship.com
> > > >
> > >
> >
> 
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
> 
> Professional Tapestry training, mentoring, support
> and project work.  http://howardlewisship.com
>

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org