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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
