tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse Kuhnert" <jkuhn...@gmail.com>
Subject Re: T5: Brandable
Date Tue, 30 Jan 2007 03:43:26 GMT
I guess I was hinting at the possibility that your different
components aren't defining different behavior so much as they are
defining different resources. (ie property keys / images / etc) If the
actual behavior is different then please ignore...If it's only the
resources that change then I think my observation would still stand..

Though I was speaking from a T4 point of view (not wanting anyone to
think I knew for sure when I don't), from what I've read of T5
everything is much the same in terms of possible functionality /
flexibility with internal tapestry services. (only better / easier /
etc of course)

On 1/29/07, Mark Stang <mstang@pingidentity.com> wrote:
> Jesse,
> The problem wasn't the internals it was how a "library" was defined in the .application
file.
>
> I have a component that is say a Support component.  It describes the running Server.
 The information in that Component is not just straight HTML, it is other Tapestry Components.
 For instance, we put a copyright on the bottom.  For our product it says our company name.
 For the OEM version, it says something else.  Now I could go through my entire application
and put if "if/else" where ever there is a difference, but how do I go back and maintain them
in the future?  Tapestry is based on Components!  Or what if I want to add another OEM partner,
do I now have to go back and put in if/else/else?  Tapestry is based on Components!  So, I
create two components, how do I tell it which one to use?  I am not going to put in if/else
all I should have to do is use a different library.  How do I do that?  The only way is to
keep the name the same but have a different location for the .library an d its pieces.  Which
means I have to either change the .application file or I have to put out a "bogus" .library
file that gets replaced in a build.
>
> What I would like to see happen in T5 is for me not to have to specify in the .application
file the location of the .libraries, I would like to have it read each .jar and if it has
a .library file, then it is a library.  The problem there is how do we determine the "name"
of the library?  For instance, I use "@branded:PingLogo", how does it associate "branded"
with a particular .library file?  Either use the name of the .library file or come up with
some mechanism for it to determine it automatically.  I don't know, but having to hard-code
it in a .application file caused me a lot of grief.  We know create a .library file for each
branding and then parse it to generate a .library that has the correct path to the components.
>
> I have a working version based on T3.  Converting to T4 from T3 and then to T5 is to
much work.  Therefore, we will either switch to T5 if I can make it work, or abandon it and
move to something else.
>
> regards,
>
> Nark
>
>
> Mark J. Stang
> Senior Engineer/Architect
> office: +1 303.468.2900
> mobile: +1 303.507.2833
> Ping Identity
>
>
>
> -----Original Message-----
> From: Jesse Kuhnert [mailto:jkuhnert@gmail.com]
> Sent: Mon 1/29/2007 6:15 PM
> To: Tapestry development
> Subject: Re: T5: Brandable
>
> Looking at it from a t4 viewpoint of services / etc I can't imagine
> this isn't do-able in some way other than having to generate
> .application files and drop in jars. (unless the jars only contain
> resources)
>
> Of course you and Howard know more, just throwing in the idea that you
> have a ~lot~ more access to how the internal works than you did in
> t3..
>
> On 1/29/07, Mark Stang <mstang@pingidentity.com> wrote:
> > Howard,
> > We ship two versions of our product.  The first is a Ping Identity version, says
Ping Identity/PingFederate all over it.  The other version is "branded" for our OEM customer
to re-sell.  In T3, in order to do this I have two jar files to implement this.  Each is a
Tapestry Library.
> >
> > When I have a "branded" component I do something like this:
> >
> >    <span jwcid="@branded:HeaderLogo"/>
> >
> > However, I have had to create hacks to work-around issues like the .application
file.  I have a Library refence:
> >
> > <library id="branded" specification-path="/com/pingidentity/component/branded/Branded.library"/>
> >
> > And then I generate a "Branded.library" for each release and copy to the above location.
> >
> > 1 <!DOCTYPE library-specification PUBLIC "-//Apache Software Foundation//Tapestry
Specification 3.0//EN" "http://jakarta.apache.org/tapestry/dtd/Tapestry_3_0.dtd"><library-specification>
> >  2   <library id="common" specification-path="/com/pingidentity/component/common/PingCommon.library"/>
> >  3   <component-type type="About" specification-path="ping/About.jwc"/>
> >  4   <component-type type="Licensing" specification-path="ping/Licensing.jwc"/>
> >  5   <component-type type="HeaderLogo" specification-path="ping/HeaderLogo.jwc"/>
> >  6   <component-type type="LoginHeader" specification-path="ping/LoginHeader.jwc"/>
> >  7   <component-type type="Support" specification-path="ping/Support.jwc"/>
> >  8   <component-type type="Welcome" specification-path="ping/Welcome.jwc"/>
> >  9   <component-type type="AdditionalResources" specification-path="ping/AdditionalResources.jwc"/>
> > 10   <component-type type="PingLogo" specification-path="ping/PingLogo.jwc"/>
> > 11   <component-type type="ConnectionLimit" specification-path="ping/ConnectionLimit.jwc"/>
> > 12   <component-type type="AdditionalAdapters" specification-path="ping/AdditionalAdapters.jwc"/>
> > 13 </library-specification>
> >
> >
> > What I would like in T5 is some support for being able to "brand" components.
> >
> > thanks,
> >
> > Mark
> >
> > Mark J. Stang
> > Senior Engineer/Architect
> > office: +1 303.468.2900
> > mobile: +1 303.507.2833
> > Ping Identity
> >
> >
> >
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
>
>


-- 
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com

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


Mime
View raw message