Re: Quality Votes on Public Betas
On 2/15/07, Ted Husted <[EMAIL PROTECTED]> wrote: In the case where we have a public beta, I wonder if we should make it a practice to hold any subsequent quality vote on user@ Is purpose of this is to get more user feedback on the voting? Or is it so users see what's going on since the beta is public? I don't have a problem with it in concept as long as it continues to be made clear that only PMC votes are binding. Greg
Re: [tiles2] Tiles TLP next steps
On 1/15/07, Wendy Smoak <[EMAIL PROTECTED]> wrote: On 1/15/07, David H. DeWolf <[EMAIL PROTECTED]> wrote: > My initial thought was that we wouldn't need the duplicate tiles2 > directory (tiles/trunk would suffice). I would think that a simple parent > pom would suffice for tiles and we may not need a parent and a master. > > I don't really care either way. . .that was just my first thought. We > can always move things around later if needed. Okay, repos/asf/tiles/trunk it is. I'll have time later this afternoon, and will do the svn move then unless someone beats me to it. I'm cool with this plan. Let's move it first. Then we can decide how to organize it after the fact. Greg
Re: [tiles2] Tiles TLP next steps
Looks like most of the infrastructure is ready, with the notable exception of a svn repo. Should we go ahead and make an announcement and move discussions to the Tiles lists? Or wait till svn is done? The website is up. What do we need to do to get something up there? I assume the current website in the sandbox is sufficient for the time being? Thanks, Greg
Re: [Tiles2] JSTL functions for Tiles taglib?
On 1/12/07, Joe Germuska <[EMAIL PROTECTED]> wrote: I think we should have more discussion before reverting anything, because I feel pretty strongly about naming, and I feel like what is there now is substantially more clear than what was there before. +1. Let's get on the same page before making any changes. I'm a bit confused. I like the idea that a tag that displays something on the page should indicate so in the tag name. Maybe we need to clarify the difference between "defining" and "inserting". Greg
Re: [Tiles2] JSTL functions for Tiles taglib?
On 1/11/07, David H. DeWolf <[EMAIL PROTECTED]> wrote: have you tried: Wow, I thought (from looking at the FAQ) that this defined a *new* attribute, not inserted one already defined. Greg
Re: [Tiles2] JSTL functions for Tiles taglib?
On 1/11/07, Joe Germuska <[EMAIL PROTECTED]> wrote: I'm finally getting back up to speed with Tiles 2 and Struts 2. I'm really pleased to see the kinds of cleanup that Tiles has gotten. However, I'm mildly "concerned" that what used to be in my JSP as this: Now looks something like this: Did I miss something in the translation? Ah, I see that I did miss tiles:importAttribute. So it could be just this: Could you not just use: I haven't used the new taglib API yet, so I'm pretty rusty. In case you missed the intent of this change we were thinking that the tag was too ambiguous. So the intent was to simplify it and make it more clear. If you have to use two lines as above I don't see that we simplified it any :-) Greg
Re: Tiles Jira
On 1/11/07, Antonio Petrelli <[EMAIL PROTECTED]> wrote: Maybe I misunderstood the term "experimental", do you mean "creating a new project under the Struts JIRA instance is the only simple way to move the issues from the sandbox"? No, perhaps I misunderstood the situation. I thought it was difficult or impossible to actually move an issue at all (i.e. change SB to TILES. It would be great if I'm wrong :-) Anyway the question is: this measure (the project under Struts JIRA instance) is definitive or temporary? It's permanent. Our final TLP Jira destination will be under the Struts project. And if it is definitive, should we move all the SB (for Tiles) issues in the TILES project? Yes I think we do need to do that. If you (or somebody) could help that would be great, but be aware that Jira notifications are not yet turned on for the project. Will they go to Struts maybe? Greg
Re: Tiles Jira
On 1/10/07, Martin Cooper <[EMAIL PROTECTED]> wrote: I'm afraid I don't either. ;-( I was just trying to do _something_ last night to at least get the ball rolling, since nothing seemed to be happening. Did you see my "ping" to the infra list? It didn't get any response so I'm wondering if it didn't actually make it through moderation. (I'm still trying to figure out when I can use GMail vs. my other POP server to send mail from my @apache address so I wouldn't be surprised if it didn't make it through. Greg
Re: Tiles Jira
On 1/10/07, Antonio Petrelli <[EMAIL PROTECTED]> wrote: Greg Reddin ha scritto: > See the INFRA > ticket for the Tiles TLP for info about porting existing tickets. What experimental tool? And anyway, is it really necessary? Since they are in the same JIRA instance, the tickets could be ported with a bulk change, moving them to the new JIRA project. IIUC a huge missing piece in Jira is the capability to move issues around. So, for example, when Shale went TLP we couldn't create a new Jira instance for Shale and move tickets to it. I think there's an experimental way to move an issue from SB-* to TILES-* if we wanted to do that, but I don't know anything about it. Greg
Tiles Jira
Thanks to Martin we now have a Jira instance set up for Tiles: https://issues.apache.org/struts/browse/TILES I suggest we start adding any new issues there immediately. See the INFRA ticket for the Tiles TLP for info about porting existing tickets. Thanks, Greg
Re: [s1] Tiles 2 integration last steps
On 1/5/07, Antonio Petrelli <[EMAIL PROTECTED]> wrote: Hello! I have finished writing Struts 1 - Tiles 2 integration module. Now I would like to know if I can add this module to its parent Do you mean add the module to Struts 1? The only bad thing about this is that it would make Struts 1 unreleasable until Tiles 2 is ready. Greg
Re: [tiles2] Tiles TLP next steps
Here's the Infra ticket for Tiles: https://issues.apache.org/jira/browse/INFRA-1083 Greg On Dec 23, 2006, at 3:38 PM, Wendy Smoak wrote: The board meeting minutes take a while to be approved and posted, but Henri mentioned on the incubator list that the Tiles resolution was approved: http://mail-archives.apache.org/mod_mbox/incubator-general/ 200612.mbox/% [EMAIL PROTECTED] I think the next thing to do is open an issue in the infrastructure JIRA project to ask for mailing lists, svn space, etc., etc. Here's the one for Shale: http://issues.apache.org/jira/browse/ INFRA-866 Do we want anything done differently for Tiles? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is this the appropriate mailing list for questions about the Tiles 2 sandbox project?
On 12/29/06, Stone, Sam <[EMAIL PROTECTED]> wrote: Is this the appropriate mailing list for questions about the Tiles 2 sandbox project? For now yes. Tiles will soon have its own top-level project and when that happens you can ask questions there. But it will likely be a few weeks before all that is set up. Greg
Re: [FWD: Re: [tiles2] Tiles TLP next steps]
> Subject: Re: [tiles2] Tiles TLP next steps > From: "David H. DeWolf" <[EMAIL PROTECTED]> > > True. Good point. I'm ok with either, but my preference would be > confluence. I haven't really used Confluence yet, but I hear great things about it. I'd like to give it a try. A couple of other things: 1. Who wants to be a moderator? 2. Should we set up a TILES JIRA instance or remain part of Struts? I understand the issue of moving tickets has a tentative resolution. Since our tickets are currently SB- I think we want to move them anyway. Greg
Re: [tiles2] Multiple container/definitions factory support
On Dec 15, 2006, at 11:43 AM, Antonio Petrelli wrote: Antonio Petrelli ha scritto: I think that the support to multiple DefinitionsFactory should be provided (that contradicts what I wrote some time ago), but I don't know if the "multiplicity" should be provided at container- level or at DefinitionsFactory-level. I think I answered myself. I am going to create a new TilesContainer (probably extending BasicTilesContainer), and a TilesContainerFactory (probably extending BasicTilesContainerFactory) to allow the creation of more than one DefinitionsFactory, associating each one to a "key", where the key will be the name of the Struts module. Sounds good to me :-) Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where is Latest tiles-test-2.0-SNAPSHOT.war???
On Dec 12, 2006, at 8:42 AM, Stone, Sam wrote: Where is latest downloadable tiles-test war file? This page tells you how to get it: http://struts.apache.org/struts-sandbox/tiles/index.html Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tiles TLP
On Dec 6, 2006, at 12:20 PM, Nathan Bubna wrote: to be constructively critical, perhaps it would help to say that i think of it as a page composition and layout management framework. perhaps that language would be useful? On 12/6/06, Nathan Bubna <[EMAIL PROTECTED]> wrote: hey now, Tiles works well without JSP too. :) I had a feeling that would come up :-) I just changed it to use your exact wording. Thanks, Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tiles TLP
On Dec 4, 2006, at 7:34 AM, Ted Husted wrote: One note on the Resolution, some elder projects like Struts and Cocoon got away with the self-referential description, but if anyone has a slightly more detailed description of Tiles, it might save a round of revisions. I made a modification that includes this description: "...the JavaServer Pages template framework currently known as Apache Struts Tiles..." Is that enough description or do you think I should add another WHERAS paragraph? Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s1+tiles2] Where does Tiles2-Struts1 integration belong?
On Dec 5, 2006, at 12:07 PM, David H. DeWolf wrote: Greg Reddin wrote: One alternative I thought of last night is to bring Struts-Tiles into the TLP as Tiles 1x. We could quickly get a GA out so Tiles would have a GA in and of itself. Then we could continue work on Tiles 2. Does anyone else see the need for that? I'd prefer not. I Ok, the tribe has spoken :-) If compatibility is the major reason why you're looking for it, I'd much rather provide a compatibility package - much like what struts2 provides for struts1. Not so much compatibility as availability. The only way to get Tiles right now is to get Struts so I've seen some "Where's Tiles?" questions on the list. But it's not really a big deal - especially since the Struts 1x releases are listed on the Struts website menu. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s1+tiles2] Where does Tiles2-Struts1 integration belong?
One alternative I thought of last night is to bring Struts-Tiles into the TLP as Tiles 1x. We could quickly get a GA out so Tiles would have a GA in and of itself. Then we could continue work on Tiles 2. Does anyone else see the need for that? Thanks, Greg On Dec 5, 2006, at 9:38 AM, Antonio Petrelli wrote: Niall Pemberton ha scritto: Better IMO to be in Struts1 - but until Tiles2 has a "GA" release the current "struts-tiles" module can't be replaced, otherwise it will prevent a "GA" release of Struts1. If you're ready to start work on this now then we could copy the exisiting code to a new "struts-tiles2" module and remove the old module once tiles has gone GA. Agreed! The other question in my mind is how much does tiles2 break compatibility with the existing struts-tiles? If it does break compatibility then perhaps we should just leave the existing "struts-tiles" module to wither and decay rather than removing/replacing. Well, Tiles 2 breaks compatibility completely. So I will create a new module. Thank you Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s1+tiles2] Where does Tiles2-Struts1 integration belong?
On Dec 5, 2006, at 7:31 AM, David H. DeWolf wrote: If Tiles is to be truly standalone, it's my opinion that all of the integration should be in the component that is embedding tiles - not in tiles itself. Otherwise, the Tiles PMC will end up having to track Struts1, Struts2, Velocity, Shale, and all sorts of other integration points. I don't think that's a good idea. So, I agree: > 1. in Struts 1, replacing the current "struts-tiles" module; +1 Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tiles TLP
+1. Sorry for the delay, I was out of town all weekend. Greg On Dec 2, 2006, at 7:19 PM, David H. DeWolf wrote: I'd like to begin the vote on the Tiles TLP Proposal [1] and Resolution [2]. [] +1 = Yes, let's ask the board to establish the Tiles TLP [] +0 = I'm in favor, to some extent. [] -0 = I'm not in favor but won't prevent it from happening. [] -1 = I'd rather see Tiles stay here or go somewhere else. [1] http://wiki.apache.org/struts/TilesTopLevel [2] http://wiki.apache.org/struts/TilesTlpResolution - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] Tiles TLP and Dimensions incubation
On Dec 1, 2006, at 9:58 AM, Antonio Petrelli wrote: Martin Cooper ha scritto: If Dimensions would ultimately be merged into Tiles, that is one thing, and that might be fine. If, however, you are thinking that Dimensions would live as a "similar concept but separate framework" to Tiles, but within the same TLP, that is quite another thing, and not something I would like to see, not to mention the ASF Board. I see. In this case Dimensions does not exist without Tiles: maybe the concept of "subproject" is wrong, it should be considered literally an extension (it contains a lot of classes that extend Tiles ones), or a component. Is the concept of "component" or "extension" incompatible with possible incubation into Tiles TLP? I haven't looked at Dimensions in detail, but I really like what it adds to Tiles in concept. I could definitely see it becoming part of the framework - either as an extension or as part of the core. Either way, I do thing it would be better to incubate it after we get the TLP going. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Tiles TLP
On Nov 30, 2006, at 10:23 AM, Wendy Smoak wrote: I'd like to see Greg or David as Tiles PMC Chair. Well I've been thinking about it a lot over the last couple of days. It's funny how my feelings are almost exactly like David's :-) The spirit is willing, but the flesh is scared, stressed out, and has very little time :-) My biggest concern right now is that my day job project is going into bi-weekly (every other week) release cycles starting tomorrow continuing for at least until the end of January and probably longer. After that we will probably be in monthly release cycles for most of the year. So.. if it comes up that a board report is due and my job deadlines are coming up then I think you know which one will get done first. Is there "grace" from the board wrt to these kinds of things? My other biggest concern is that I've only been an apache committer for about a year and a PMC member for a few months. I'm still pretty green when it comes to all the foundation stuff. OTOH I have been following it for about 6 years and have picked up a lot of things by observation. So, ok, I'll do it. I'll probably need lots of guidance from some of you for a while and probably some help getting things done, but I'm willing to take on the task. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving OverDrive to Apache Labs
Sounds good to me. Greg On Nov 29, 2006, at 9:49 AM, Ted Husted wrote: If no one minds, I'd like to apply to Apache Labs to host the OverDrive code, now found in the Struts sandbox. It's greenfield C#/ASP.NET stuff, and there's no direct connection to the Struts codebase. * http://labs.apache.org -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduation Options (was Re: [PROPOSAL] Updated Tiles Graduation Proposal)
On Nov 28, 2006, at 1:48 PM, David H. DeWolf wrote: And, who's volunteering to Chair? Perhaps it goes without saying, but the chair is actually appointed by the ASF board, we can only make a suggestion. I went digging for some information about the role of a chair and found these: http://www.apache.org/foundation/how-it-works.html#pmc http://www.apache.org/dev/pmc.html#chair http://www.apache.org/foundation/faq.html#why-are-PMC-chairs-officers http://www.apache.org/foundation/bylaws.html (Section 6.3) What I'm not sure of is whether there are any prequalifications for being a chair, for example, does a chair already have to be an ASF member or a PMC member of an Apache project? Or is it basically "whoever the board wants to appoint"? Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduation Options (was Re: [PROPOSAL] Updated Tiles Graduation Proposal)
On Nov 28, 2006, at 1:48 PM, David H. DeWolf wrote: Greg Reddin wrote: On Nov 28, 2006, at 1:19 PM, David H. DeWolf wrote: Ok, I'm convinced. I'm on board with a Tiles TLP. If someone doesn't beat me to it, I'll go ahead and write something up on the wiki. I'm still thinking but close :-) Would the current TLP proposal suffice? Good. We need one thinker in the group :) My plan was to use it as a template. I think there's some updating to do. Is it ok to update it directly or do we need it around for reference and history? I think the wiki keeps track of changes so history is built in. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduation Options (was Re: [PROPOSAL] Updated Tiles Graduation Proposal)
On Nov 28, 2006, at 1:19 PM, David H. DeWolf wrote: Ok, I'm convinced. I'm on board with a Tiles TLP. If someone doesn't beat me to it, I'll go ahead and write something up on the wiki. I'm still thinking but close :-) Would the current TLP proposal suffice? What about other people? Are David Geary and Matthias Wessendorf listening? They were on the original TLP and might be interested in joining the project. Craig also indicated his interest. Wendy? You're on every other apache project, might as well join this one too :-) And let's not forget Cedric, if he's interested. Greg David Nathan Bubna wrote: On 11/28/06, David H. DeWolf <[EMAIL PROTECTED]> wrote: ... Perhaps I'm looking at this too selfishly, but I'm thinking that if nothing else the teams can help each other with the infrastructure and burden of being a TLP. For example: - Moderating Mail Lists - Board Reports - Managing Jira - Community Oversight - etc. . . and the burden of all of these grows with the size of the community. true, it's not a linear curve, but i think the benefits of shared interest in a codebase are superior to those of size. It seems to me like those types of tasks can take a lot of development time away from a small team. I've heard of PMC Chairs that are consumed by all of this overhead and stop committing code. I don't ever want to get to that point and it seems possible considering the fact that there are only 3 of us - 2 that currently commit code. this is especially prone to happen when the scope of the PMC is too big. too much to oversee and keep track of. That said, I do think there's much more potential for commit overlap than you give credit. Simply having access to the repo of a sister project might spawn some interest. I know that I'd be apt to dive into FileUpload or WebParts if I had commit access. I've used both before but haven't contributed because the burden was too much for the benefit. it might, but i'd advise against counting on cvs access alone to spur involvment. At the same time, while I'm sure Dimensions or Scopes are great, I just don't have the need for them right now. And because of that, I'd be less apt to contribute. true, but those interested in dimensions or scopes (i'm assuming they're Tiles-dependent here) are much more apt to contribute to Tiles. and those who already know Tiles should be much more capable of jumping in on dimensions or scopes (being closely related projects) than they are on FileUpload. consider email: it should be easier and quicker for a Tiles committer to follow email about a closely related/dependent project than it is to follow emails about unrelated ones like FileUpload. lack of focus will cost all the developers time, not just the PMC chair. In other words, I don't think it's "dependency" that makes people contribute, I think it's weighing the benefit against the burden. If we lower the burden for key people, they may come to play. in both cases (Dimensions/Scopes vs FileUpload/WebParts) you are talking about lowering the burden equally from an infrastructure point of view, so that's a moot point. and the conceptual burden of contributing to a dependent project (Dimensions/Scopes) is already lower than that of an unrelated project (FileUpload). so, it's only the benefit side that is really in question here. as to that, investment in a project dependent on Tiles leads to investment in Tiles much more often than investment in FileUpload would. yes, in the other direction (starting with investment in Tiles, like you, and looking at Dimensions/Scopes), the benefit is highly personal and thus essentially arbitrary, but it still seems more likely (due to the lower conceptual burden). take the umbrella metaphor itself: umbrellas are much easier than tarpaulins to manage because they have a specific, central pole to which all the rest is firmly connected. likewise, putting Tiles, FileUpload, etc together in one project may have some benefits but is going to be hard to manage effectively and move forward together (Jakarta Commons and Jakarta itself are examples of this). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduation Options (was Re: [PROPOSAL] Updated Tiles Graduation Proposal)
On Nov 28, 2006, at 9:46 AM, David H. DeWolf wrote: Greg Reddin wrote: Here's the viable choices as I see them: 1) Jakarta Web Components Subproject - What components will make up this list? Who all needs to be involved in the discussion? I'm not inclined to follow this path as Jakarta is already quite a diverse group that is trying to become more centralized/focused in order to build more community. Brining in a new developers with no other involvement in that community into the mix seems to create more disconnect - not more community. I would revise this option to be a Jakarta Tiles Subproject eventually to be part of a Web Components grouping if and when that is formalized. That seems to be the more palatable option for the Jakarta community. However I expect even this to come under some objection and take a lot of effort to push through with the diverse community. 2) Apache Web Components TLP - What components will make up this list? Who needs to be involved in the discussion? What's the process to proceed? This is my preference. I think the next steps would be to follow up with the other potential projects to see if they are even interested. The core ones that I'd start talking to are: - Tiles (Apache) - Jakarta Commons File Upload (Apache) - Java Web Parts (SF) - XAP (Apache Incubator) I see this as being difficult to get approved, much less operational. I think we need to have a real convincing argument for all these things to live together before we head down this road - not just for political reasons but practical reasons also. I'm not sure how this helps our community situation. Why would a Web Parts developer start contributing to Tiles just because they are part of the same TLP. I'm a Struts committer, but I've contributed very little to anything outside of Tiles. I'm also a Shale committer, but I've not contributed much to the other parts of that project yet either. Community doesn't just happen because we live in the same neighborhood or even the same house. There has to be a common goal that will cause people to want to work on Tiles specifically I think. It would make sense to bring Dimensions and Scopes into a Tiles project. They deal directly with Tiles. People interested in one will be interested in the other. But the above list of components just don't have enough in common to build that kind of community IMO. BTW, your statement about simultaneous releases really scares me :-) I didn't follow the discussion wrt Struts 2, but I'm having a hard time envisioning a release ever happening under that kind of strategy. 3) Apache Tiles TLP - Seems we could do this here and now and submit a proposal to the board. Who else should we bring into the discussion? Doable, and probably the easiest to get going - but also the hardest to maintain. It doesn't seem to me like there are enough interested parties to carry the load. The original proposal that Ted referenced included the following three individuals: David Geary, Nathan Bubna, Matthias Wessendorf. I wonder if they are still interested. The potential lack of community is a risk, but it would be a focused group. When all questions and contributions are diverted to that list the need will become evident and the community will grow or we'll get burned out and the project will go dormant. But there's no reason to try to push a project doesn't have enough interest to support itself. Sorry to be such a flip-flop. I've been thinking so much about the "next step" that I haven't taken the time to think through the big picture. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduation Options (was Re: [PROPOSAL] Updated Tiles Graduation Proposal)
But we still get a lot of questions about Tiles and Nathan's point about users being contributers is valid. Perhaps some of them will step forward and contribute patches as they see the need. The need will be way more apparent in a TLP with a small focused community. Greg On Nov 28, 2006, at 10:55 AM, Antonio Petrelli wrote: Greg Reddin ha scritto: There's a lot of people who *use* Tiles, but how many of them are legacy users who don't want to grow with it? How many of them will be contributors? Well, it's under our nose: how many Struts users are contributors? Currently Struts is a worldwide project deployed in thousands of projects, but how many of them are contributors? And how many of them still uses Struts 1.1? Since Tiles is a niche project (optimistically 1/100 of Struts users) we must expect a much smaller contribution. Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduation Options (was Re: [PROPOSAL] Updated Tiles Graduation Proposal)
On Nov 28, 2006, at 9:46 AM, David H. DeWolf wrote: 3) Apache Tiles TLP - Seems we could do this here and now and submit a proposal to the board. Who else should we bring into the discussion? Doable, and probably the easiest to get going - but also the hardest to maintain. It doesn't seem to me like there are enough interested parties to carry the load. Ok, so here's the really hard question - do we have a community? The number of people contributing to Tiles has grown from one to three (and I haven't really contributed anything but ideas in a while). I don't mean in any way to diminish the contributions of those who built Tiles in the first place or initially moved it to the sandbox. But where does it go in the future? I don't want to spend a whole lot of time lobbying for and building a TLP for three people. I suppose we could get it going to test the waters - if you build it they will come. But I'm not sure if they will come yet. There's a lot of people who *use* Tiles, but how many of them are legacy users who don't want to grow with it? How many of them will be contributors? I'd love to hear thoughts from people who have gone down this road with other projects as well as from David and Antonio. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Updated Tiles Graduation Proposal
Since we've failed to build consensus, I've published a versioned snapshot that will have to suffice for 2.0.2 and I will begin to drive the effort for TLP :( - it's not my preference but it will have to work. Hang on, slow down just a bit :-) Before we jump off the TLP cliff let's make sure we know all the options and have consensus from everybody involved. Here's the viable choices as I see them: 1) Jakarta Web Components Subproject - What components will make up this list? Who all needs to be involved in the discussion? 2) Apache Web Components TLP - What components will make up this list? Who needs to be involved in the discussion? What's the process to proceed? 3) Apache Tiles TLP - Seems we could do this here and now and submit a proposal to the board. Who else should we bring into the discussion? Options that have been discussed and rejected: 1) Struts subproject - Struts does not need to become an umbrella. 2) Jakarta Commons component - Tiles is more of a framework than most of the components under commons. Several people have voiced their objection to this approach. 3) Struts2 Tiles Plugin - Removes the "standalone" nature of Tiles. So... of the three viable options, let's discuss and decide where to go from here. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Updated Tiles Graduation Proposal
On Nov 28, 2006, at 7:48 AM, Ted Husted wrote: At this point, I'm -1 on a Tiles subproject. It was always the intention for Tiles to apply to TLP when the time came, and the time has come. I don't think that was a given - at least not when I came on board. A TLP was always an option, but in the discussions I've been a part of the Jakarta option has always been in play as well. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Updated Tiles Graduation Proposal
On Nov 28, 2006, at 2:40 AM, Antonio Petrelli wrote: Instead of creating a Jakarta subproject for web components, why don't we open a TLP for web components and then add Tiles? Since there are topic-based projects (think of ws and logging), this would be a nice place to put web stuff, and I suppose that could be a REAL umbrella project. I think that's a reasonable idea. The web components route is my favorite option for a permanent home whether it lives under Jakarta or not. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
No problem. I just haven't had time to formulate a response yet :-) Greg On Nov 27, 2006, at 2:02 PM, Ted Husted wrote: Sorry for the rant. I would have just sent the last two paragraphs, but the phone rang, and I pressed the wrong button :( On 11/27/06, Ted Husted <[EMAIL PROTECTED]> wrote: Here's the thing: If all these other projects depend on Tiles, then why are they not contributing? If other people won't contribute to Tiles in the sandbox, they won't contibute to Tiles as a Struts subproject either. If the Tiles group wants to build community, then cut the apron strings and move on. One approach would be to update the TLP proposal and draw up a corresponding Commons Subproject proposal, and invite people from other communites to sign up as a committer to one or the other. If we want other people to contribute, then we should *invite* them to contribute, and stop casting Tiles as a Struts thing. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
On Nov 25, 2006, at 9:32 AM, Ted Husted wrote: Could we also document the alternative of moving the org.apache.tiles packages *into* the struts2-plugin? The proposal cites three problems: 1 Can't release 2 Not visible 3 Not permanent As part of the Struts2 Plugin, problems 1 and 2 will be solved. The problem I'm most concerned about with this proposal is problem 1. Our main goal here is to find a point where we stop adding revolutionary features and start moving towards a GA release. To me the most urgent "visibility" problem is that people can't download an actual Tiles release. They have to download a snapshot build. So the Struts 2 plugin and the Shale view handler have to depend on a snapshot release. Other projects, like MyFaces, just depend on Tiles 1.x. My initial goal is to give people a Tiles 2.0.0 that is an Alpha-quality release and I think the other Tiles developers are on the same page. If all we want to do is separate Tiles from the core, then mission accomplished, put the packages back into the plugin. I disagree. If we do that Tiles is not standalone anymore and the mission is no longer accomplished. Tiles 2 currently has no dependencies on Struts and contains no integration code with any other framework. Integration with another framework is provided by the other framework. That's the whole idea of making it "standalone". If we put the packages into the plugin it now has an integration layer with Struts 2. When we decide where it will ultimately live we will have to separate the plugin from the core Tiles framework. That means separating codebase, test cases, doc, build files, etc. I want to keep Tiles standalone, graduate so we can release an alpha, then put our focus into knocking out the rest of the issues and deciding where the permanent project will live. Realistically, making Tiles a subproject is not going to suddenly create community interest in the codebase. That didn't happen for the other subprojects, that we later merged back into Struts 1, it really didn't happen for Shale either, and it's unlikely to happen to Tiles. To create community, a codebase needs to stand on its own or be part of a larger umbrella project, like the Commons or the ASF itself. I agree. I don't see this move as building community. It's just a stepping stone on the path to independence. As part of the Struts 2 plugin, other projects, like Shale, and Spring, and WebWork, would be able to make use of Tiles, which is the primary goal. We can make the Tiles plugin as visible as we want it to be, and it will be just as easy to promote Tiles to TLP later, should other developers materialize (or remateralize). Yes, but then the plugin would be part of Tiles. I personally don't want that and I think that goes against the original reason for creating the standalone Tiles project. I'm OK with listing Jakarta Commons as a home for Tiles, as well as a new Jakarta Subproject or even TLP for Web Components. I'm also OK with listing the s2 plugin as an option, even though it's not an option I'm in favor of. But our focus here is not trying to find the permanent home for Tiles. We are intentionally leaving that question open for the time being and trying to move Tiles to a place where it will stabilize. The reason the subproject appeals to me is that we can simply copy the tiles sandbox svn tree out of the sandbox and cut an alpha release. Then we can start trying to answer the bigger questions. Any other path either 1) takes us backwards with regard to independence (struts2-plugin) or 2) requires a whole lot more community-building and red tape before we can move any further (jakarta, TLP, etc.). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] tiles-documentation/showcase app
On Nov 24, 2006, at 1:39 AM, Antonio Petrelli wrote: But the documentation app is, in fact, a showcase, except of some static docs (that can be moved to xdocs), so from my POV it is easier to adapt it to be showcase than to create a new showcase app from scratch. Ok, I'm cool with that. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] tiles-documentation/showcase app
On Nov 23, 2006, at 2:05 AM, Antonio Petrelli wrote: I don't know, my POV is that tiles-test could be used for all tests, even the simplest ones. For example, one day a user notices a strange effect on a tag and opens a JIRA issue, so we resolve it and put a Selenium test case. Adding this test case to the showcase would be unuseful for the user. I think that tiles-documentation (or tiles-showcase) will be a nice way to learn Tiles by examples, and it should not be tainted with test cases. That's a good point. If we want to go that route then I'd propose that we build a separate showcase app instead of trying to make the documentation app fit it. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Graduate Tiles2 From the Sandbox (was Re: Releasing Tiles)
On Nov 22, 2006, at 12:51 PM, David H. DeWolf wrote: Please find the Tiles2 graduation proposal draft below. I look forward to your feedback . . . http://cwiki.apache.org/confluence/display/S2WIKI/Tiles2+Graduation +Proposal +1 with one clarification. I think the Community Involvement section should either be rewritten or removed. Technically, a release requires three PMC votes, not just committer votes. Since that's an Apache directive not a Struts directive, I'm not sure if it's necessary to even list the requirement. Maybe it should be changed to note the active participants in the project. Am I correct? Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing Tiles (was: Re: [s2] 2.0.2 release this weekend)
On Nov 22, 2006, at 12:07 PM, Wendy Smoak wrote: Personally, I don't think it's a good idea for either _project_ (for Struts to be an umbrella project, or for Tiles 2 to be so closely associated with Struts.) However, it seems to be the best choice right now for the people involved. That's my feeling too. I'd like to see it promoted on a temporary basis so it can get a release out without all the overhead of starting a whole new project. I would consider its promotion temporary with the future view being a TLP or Jakarta subproject. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing Tiles (was: Re: [s2] 2.0.2 release this weekend)
On Nov 22, 2006, at 11:55 AM, David H. DeWolf wrote: Ok, so what should I do to drive this to a decision? If we have any sort of consensus, I'd like try to get it done before the struts 2.0.2 release so that we can have the tiles plugin use an alpha release. That may not be doable at this point, but I'd like to at least try. I think we just need a proposal and a vote :-) I'd do it myself, but I just don't have time right at the moment. But I'll +1 it. Let me know if I'm trying to move to fast :) Not at all. The sooner the better. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] tiles-documentation/showcase app
On Nov 22, 2006, at 11:48 AM, David H. DeWolf wrote: What is our goal with the tiles2 documentation webapp? To remove it :-) I began the process of extracting the main points from the doc and moved them into the Tiles 1.x doc that is currently published. I never was convinced that I combed it for all the info needed, but eventually I hope the Tiles doc will be complete and we can get rid of this app. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing Tiles (was: Re: [s2] 2.0.2 release this weekend)
On Nov 21, 2006, at 9:15 AM, David H. DeWolf wrote: What I'm more concerned about is the community/oversight. I think the scope of the Tiles 2 community remains to be seen. There are several other templating solutions out there. How will Tiles 2 be accepted when compared with Sitemesh, etc? I don't know. The JSF community has Facelets and Clay, so Tiles support is more of a legacy thing. The thing we do have going for us is that there's a lot of users who are familiar with Tiles 1.x. Migration from Tiles 1.x to Tiles 2 might be easier than, say, Tiles 1.x to Sitemesh for those who don't want to learn too many new things. It also helps that the Tiles integration for Struts 2 and Shale is Tiles 2 exclusively. But the risk is that people who know Tiles 1 and start using Struts 2 or Shale will not be willing to port their Tiles knowledge to Tiles 2 and would rather take on a different framework. So, all we can do is work it up, release it, and doc it and see what happens. I tend to think the earlier we get it out of the sandbox the better. A snapshot project in the sandbox just doesn't have the same credence as even an alpha that has a real project commitment behind it. For me personally, I'll support Tiles whether it's a TLP, part of Jakarta, or part of Struts. Honestly, I'm not interested in spearheading a TLP right now. I'm just not yet convinced enough that the community will come along and make the effort worth it. But if someone else wants to write up the proposals and be the "chair" and whatever else needs to be done, then count me in as a full-time supporter. It's possible that my situation will change when my day job settles down a bit, but right now I just don't have the bandwidth to kick it off. I think the Struts community has made it clear that we want Struts to be focused on building an MVC framework and not necessarily all the stuff surrounding that (and I agree with that BTW). So unless that sentiment has changed I think we have to stay in the Struts sandbox until we have enough momentum to either join Jakarta or go TLP. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing Tiles (was: Re: [s2] 2.0.2 release this weekend)
On Nov 21, 2006, at 9:30 AM, David H. DeWolf wrote: procedural ones which we MUST take care of but are trivial (Copyright notices, and Id Keywords, I do think this one's critical to get out before alpha. retroweaver distributions), Probably could wait til after alpha. 1) Do we need to support EL for an alpha release? 2) Must we flush out all documentation for an alpha release? 3) Do we need to extend the putList features (SB-60) I think we could release an alpha without the above. We know they are planned features for a final release, but an alpha would allow people to get the stuff in their hands and start playing with it. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] Servlet 2.3 or 2.4?
On Nov 17, 2006, at 6:30 AM, Antonio Petrelli wrote: * compile against Servlet 2.4, though I think it can be used under Servlet 2.3 environments, declaring the problems with JSP < 2.0 pages (that miss EL); +1. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF Notice file for Tiles 2
I think most discussions have leaned towards moving Tiles out of Struts once it gets ready to graduate from the sandbox. So I'd prefer Apache Tiles myself. Other thoughts? Greg On Nov 9, 2006, at 6:58 AM, Antonio Petrelli wrote: Hello! What do you suggest to put in the "NOTICE.txt" file for Tiles 2? Apache Tiles or Apache Struts Tiles or what else? Thank you Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Tiles 2 Snapshots
You rock :-) Thank you very much for taking care of this. Greg On Nov 7, 2006, at 9:41 PM, Wendy Smoak wrote: On 11/7/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: I'll publish it later tonight as 2.0-r468346-SNAPSHOT, and change the dependencies in the Shale and Struts builds. This is done. If you want to use the October 27th r468346 snapshot, use this dependency: org.apache.struts.tiles tiles-core 2.0-r468346-SNAPSHOT Publishing the snapshot involved changing the version number in all the Tiles 2 poms, then executing 'mvn deploy'. The version is "set" in tiles-parent, but then tiles-core and tiles-test mention the version when declaring the parent. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] AttributeTag.preprocessAttribute disappearance
On Nov 6, 2006, at 8:42 AM, Antonio Petrelli wrote: David H. DeWolf ha scritto: By the way, what's the use case for putting definitions in a jsp? Why would someone prefer that method over another. . . That's a good question. In real applications I never used JSP- configured defininitions, but removing them could break all the applications. It is not like removing a tag library because it is redundant, removing a functionality that will not exist anymore can be harmful. Just my 2 eurocents Yeah, I can envision a use case where someone may want to define defs in a JSP page so they are dynamic. I've never done it, but it could be done :-) Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] definitions factory (was Re: [tiles2] ComponentDefinitions)
On Nov 6, 2006, at 7:07 AM, David H. DeWolf wrote: Here is what I envision: 1) DefinitionsReader - parse an input stream into a map of definitions. 2) DefinitionsFactory - manage the creation of definitions. instantiate the appropriate readers, manage refreshes. 3 DefinitionsManager - cache definitions, resolve dependencies, manage localization. This allows us to pull the caching of definitions outsite the factory and releave it of that responsibility. By doing so, it's only responsible for the creation/management of definitions which it creates in the firstplace, and the manager is responsible for pulling all of the definitions together into a single location. I like this approach. I think it cleans up the interface and makes responsibilities more cohesive. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] ComponentDefinitions - exposed implementation detail?
On Oct 31, 2006, at 3:10 PM, David H. DeWolf wrote: I'm wondering why the ComponentDefinitions interface has been exposed outside of the DefinitionsFactory. To me, this class seems like an implementation detail of the factory itself, and it should not be exposed. If you look back at Tiles 1 you'll see that DefinitionsFactory and its descendants pretty much contained all of the functionality that we've separated into DefintionsFactory and ComponentDefinitions. It was both a factory and a container if you will. This was especially true if you drilled down into xmlDefinitions and the classes under that. A lot of core Tiles functionality was embedded deep into the XML version of the implementation and not exposed on the API. Let's keep in mind the value of separation of concerns. I don't think we want the factory to do too much. Remember what the purpose of a factory is - to create objects and nothing more. I think anything beyond the creation and storage of definitions should be delegated outside the factory so that if someone wants to override the creation and storage functionality, but wants to keep other pieces in place they can do that. See further comments below: 1) Encapsulate the refresh logic in the DefinitionsFactory. The filter will change to: if(factory.refreshRequired()) { // replace refresh logic with a call // to the factory, removing the reference // to ComponentDefinitions factory.refresh(); } I'm OK with this because it still seems related to "factory" like code to me. The factory is being used for manufacturing and repair in this case :-) That doesn't bother me. 2) TilesUtilImpl only exposes the ComponentDefinitions in order to allow the Filter (#1) to access them. This reference can easily be removed. This is true, but TilesUtilImpl is likely going to be replaced by our container API. So maybe the container API replaces ComponentDefinitions. That's really what ComponentDefinitions was created for - to separate container logic from creation logic. So, if the container exposes everything that's currently being taken care of by ComponentDefinitions I'm cool with it. But, again, I want to avoid a monolithic API that does too much. We need to find the sweet spot of APIs that are small and manageable, but yet complete. 3) Encapsulate the hierarchy resolution within the DefinitionsFactory, allowing the resolution to occur during initialization. Looking at ComponentDefinitions right now, it provides APIs to add definitions, get definitions, and resolve inheritances (and some ancillary things that might just be side effects). DefinitionsFactory has APIs to get and read definitions. There's some overlap, redundancy, and perhaps misplaced responsibilities. I do think we need to rethink some things, but I'm not convinced that dumping it all into the factory is the right thing to do. Maybe we can back up a bit, identify the core responsibilities, and decide where each one fits between the factory, the container, and whatever else. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] Changes in tag libraries
I wonder if it would be possible to provide the combined tag as well for people who are porting applications. There are two questions that come to mind: 1) Have we already made porting to Tiles 2 a non-trivial task by all the changes we've made, and 2) are we ready for the barrage of support questions about how to convert an application? I want to make it easy for users to switch, but I also want to make improvements where we can. It's a hard tightrope to walk. Greg On Oct 31, 2006, at 9:43 AM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote: Antonio Petrelli asked: [EMAIL PROTECTED] ha scritto: Antonio Petrelli wrote: In the Struts Users and Shale Users mailing lists we (Greg and I) encountered several people confused by the different meaning of , so we decided to specialize this tag in different tags, I chose only the names. And I don't think that anyone used to insert a definition in a case, a template in another case, or an attribute in a third case. The split removes the confusion. Or moved it. I'm certainly confused. Sorry, what do you mean? Just that the confusion seems to have moved from the people who found a single tag confusing to me, who finds a proliferation of tags confusing. Likely if I were using Tiles 2, I would learn to get used to it. On the other hand, the fact that it will be more work to port a Tiles 1 app to Tiles 2 will likely delay that learning. Oh well. Que sera, sera. I don't have the time, right now, to go back through the list archives to understand the advantages of this change. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] Logging Consistency
On Oct 31, 2006, at 9:59 AM, Martin Cooper wrote: On 10/31/06, David H. DeWolf <[EMAIL PROTECTED]> wrote: Tiles currently uses both commons-logging and jdk1.4 logging. I'd like to make this consistent. Which one is preferred? IMO, Commons Logging. That way, people can have one coherent log for their entire application. +1. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] Taglib refactoring finished?
No objections here. Greg On Oct 30, 2006, at 6:34 AM, Antonio Petrelli wrote: Hello! I think that the taglib refactoring, i.e. all the deprecated/ duplicated stuff has been removed, has finished, so I think that SB-21 can be resolved: http://issues.apache.org/struts/browse/SB-21 I had a little doubt about UseAttributeTag and ImportAttributeTag, but they do different thing (ImportAttributeTag can import all attributes in a different scope, while UseAttribute creates also a scripting variable). Have you got anything in contrary if I resolve the issue? This way I can go ahead refactoring the DTD of Tiles definitions configuration files. Thank you Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 + Tiles 2 build failure
On Oct 27, 2006, at 9:58 AM, David H. DeWolf wrote: Since we are changing tiles and flushing out the 2.0 api, I don't think we can prevent this type of failure for people that use snapshots. The current failure comes from 2 things: the view preparer changes that were made and the tiles context changes that were made. Yes, and the only 2 projects currently using Tiles 2 are Struts 2 and Shale and between the two of us we have committer rights to change both so I'm not too worried about it. It will encourage us to get the release out :-) This is a great reason to drive towards an initial release :) What you said ;-) Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 + Tiles 2 build failure
On Oct 27, 2006, at 9:52 AM, Wendy Smoak wrote: On 10/27/06, Greg Reddin <[EMAIL PROTECTED]> wrote: What happened? Is the TilesResult dependent on a snapshot or nightly build or what? I would hope we could make changes like this without breaking people until the changes are done. Yes, Struts 2 depends on a snapshot of Tiles 2. So does Shale. And I published Tiles snapshots last night. Ok, that's cool. So I suppose I need to fix Shale too, huh? :-) We might want to switch to timestamped snapshots (remove the uniqueVersion=false in the pom) so that projects can choose when to move up to the latest bits. That might be a better ides. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] Tiles Container API? (was Re: [tiles2] TilesContextFactory refactor)
On Oct 26, 2006, at 8:03 AM, David H. DeWolf wrote: I'll probably have some time to finish up the TilesContextFactory configuration today and start doing some work on removing duplication. Once I get through that I'll start putting some container ideas down into code. The first step of that process will be to define the tiles container api. What are those things that we want to expose to the world? It doesn't seem like much. The majority of what people will do with Tiles is plug it into another architecture, so we need to focus on the points where it interfaces with MVC architectures I think. Beyond that, there will be cases where people want to create, modify, and access definitions and attributes. I'd say keep the public API as small as possible and add to it as requests come in. Antonio may have more input since he's working with some Tiles extensions. Do we prefer to do the container work in a branch, or continue working on it in the trunk? Either way is fine with me. I would prefer to just do it in the trunk since it can be done incrementally. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 + Tiles 2 build failure
On Oct 27, 2006, at 6:40 AM, David H. DeWolf wrote: Correct, I've got a patch prepared and will commit it once I deploy the new tiles snapshot - just got my unix perms yesterday. What happened? Is the TilesResult dependent on a snapshot or nightly build or what? I would hope we could make changes like this without breaking people until the changes are done. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] TilesContextFactory refactor
On Oct 24, 2006, at 3:23 AM, Antonio Petrelli wrote: David H. DeWolf ha scritto: The one negative to this approach is that it will eliminate the ability to support multiple contexts (when tiles is packaged in a common classloader). The TilesUtil currently appears to be implemented in a way which suggests that the original intent was to support multiple contexts. That said, the support is already only partial since Tiles utilizes several static accessors and instances such as TilesUtilImpl will be shared across applications. Now the question is: Why do you need multiple TilesApplicationContexts? Just curious :-) I think David was asking the same question. If Tiles is deployed in a common classloader (i.e. Tomcat's common/lib directory) you'd want each application to have its own TilesApplicationContext since each application would have its own instances of the internal components wrapped by TilesApplicationContext. That just sounds like more trouble than it's worth supporting IMO :-) But, inevitably somebody will plunk the tiles JAR down in common/lib and start hollering about things not working. So we should probably at least document the issues with it. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] TilesContextFactory refactor
On Oct 21, 2006, at 10:02 PM, David H. DeWolf wrote: The one negative to this approach is that it will eliminate the ability to support multiple contexts (when tiles is packaged in a common classloader). The TilesUtil currently appears to be implemented in a way which suggests that the original intent was to support multiple contexts. That said, the support is already only partial since Tiles utilizes several static accessors and instances such as TilesUtilImpl will be shared across applications. I don't personally want to go to great lengths to support running Tiles in a common classloader. If it happens to work then fine. But I would not call it a best practice. Maybe there's situations where it is warranted, but I haven't personally encountered those. The second approach that would solve this issue would be to refactor the codebase to eliminate the prevalent use of static methods. Instead, all tiles functionality could be configured and encapsulated into a self contained "container" which would be cached and retrieved when needed. I'm definitely in favor of this approach. I have no problem with static methods but, as Antonio has pointed out, it makes things more difficult to configure. I'm having a similar issue with MyFaces Tomahawk components where I'd like to modify a renderer but the modification is in a non-configurable static utility class. Also, caching objects as static members of utility classes in a multi- threaded environment is problematic at best. So, I'm definitely in favor of this aspect. In this scenario, the configuration servlet, filter, or listener, would create the container and provide access to it from a publicly available place (perhaps the underlying context). Whenever tiles were needed, the client would retrieve the container and invoke it. Services like the TilesUtil would be provided by the container, not statically accessed. I like this approach. Since this is the place where other frameworks will have the most interaction with Tiles we should try to make it as straightforward as possible. This kinda goes along with SB-56 [1] that you opened doesn't it? Greg [1] https://issues.apache.org/struts/browse/SB-56 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] TilesContextFactory refactor
On Oct 18, 2006, at 6:52 AM, David H. DeWolf wrote: 1) TilesContext is refactored into two different contexts - TilesContext and TilesRequestContext. Only one instance of the TilesContext should exist within the application and it will be used to provide application scoped functions (e.g. getResource() or getInitParameters()) . The TilesRequestContext will provide request/response specific operations (e.g. include() or getParameters()). At first I didn't like the separation, but now I do after looking at your patch. It makes sense that you would put request-based stuff into a separate class from application-scoped stuff. I have two small concerns: 1) The name TilesContext: Perhaps we should change it to TilesApplicationContext. 2) How will Tiles be used from other frameworks? Here's an example from Shale. Shale provides a TilesViewHandler with the following code (the code is similar to what is used in other frameworks like Struts2's TilesResult class): ExternalContext externalContext = FacesContext.getCurrentInstance() .getExternalContext (); Object request = externalContext.getRequest(); Object context = externalContext.getContext(); ComponentDefinition tile = null; try { TilesContext tilesContext = TilesContextFactory.getInstance (context, request); tile = TilesUtil.getDefinition(name, tilesContext); } catch (NoSuchDefinitionException nsex) { log.error("Couldn't find Tiles definition.", nsex); } catch (DefinitionsFactoryException dex) { log.error("Tiles error", dex); } return tile; After your refactoring the code above will look like this: ExternalContext externalContext = FacesContext.getCurrentInstance() .getExternalContext (); Object request = externalContext.getRequest(); Object context = externalContext.getContext(); ComponentDefinition tile = null; try { TilesContextFactory contextFactory = new BasicTilesContextFactory(); TilesContext tilesContext = contextFactory.getInstance (context); TilesRequestContext tilesRequestContext = tilesContext.createRequestContext(request, response); tile = TilesUtil.getDefinition(name, tilesRequestContext); } catch (NoSuchDefinitionException nsex) { log.error("Couldn't find Tiles definition.", nsex); } catch (DefinitionsFactoryException dex) { log.error("Tiles error", dex); } return tile; The only reason I have to create a TilesContext above is because I need a TilesRequestContext. What if the factory provided methods to create either the TilesApplicationContext or the TilesRequestContext instead of the TilesContext being required to create the TilesRequestContext? Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] New Struts Committer: David DeWolf
On Oct 20, 2006, at 1:40 AM, Antonio Petrelli wrote: Niall Pemberton ha scritto: Welcome, David ... and in Don's words "now you can commit your own dam patches!" Welcome David! By the way, I recall this words written by Greg, except of "dam" :-) Nope, that was all Don :-) I haven't committed any of his patches yet, but I still promise I will look at them :-) Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] TilesContextFactory refactor
On Oct 19, 2006, at 10:24 AM, David H. DeWolf wrote: Antonio Petrelli wrote: David H. DeWolf ha scritto: 1) TilesContext is refactored into two different contexts - TilesContext and TilesRequestContext. Only one instance of the TilesContext should exist within the application and it will be used to provide application scoped functions (e.g. getResource() or getInitParameters()) . The TilesRequestContext will provide request/response specific operations (e.g. include() or getParameters()). It seems like a good idea, anyway I would like to know from Greg if it is ok for him. Greg, any thoughts? I'm interested in your opinion too. Yes, I'm looking at it. I hope to respond by the end of today. Sorry for the delay. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] Classpath Configuration
On Oct 13, 2006, at 1:53 AM, Antonio Petrelli wrote: You know Greg, some ideas come at night! I think that the particular case of David CAN be resolved using a different TilesContext, at least a TilesContext that returns a different URL when calling to getResource. To accomplish it, TilesContextFactory needs to be a configurable regular class, and I opened an issue for this problem: http://issues.apache.org/struts/browse/SB-44 That's a good point. The UrlDefinitionsFactory will (should) handle any URL. So, it shouldn't matter whether the URL comes from the servlet context or the classloader. BTW, I'm in favor of SB-44. I think that's a good idea. Thanks, Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] Classpath Configuration
On Oct 12, 2006, at 3:42 AM, Antonio Petrelli wrote: I don't know if it's useful, but I submitted a patch (I don't know if it applies correctly though) some time ago to enable an easier extension to Tiles defiinitions factory: https://issues.apache.org/struts/browse/SB-28 You're right, I forgot about that. I looked briefly at the patch and I have no opposition to it. I originally didn't like the fact that it excluded Locale as a first class citizen when determining which definition to return. I'm still not real excited about that part. I think locale-based definitions are a core feature of Tiles, not an optional feature. By replacing locale with TilesContext we've essentially made it optional. The fact that it processes by locale is only an implementation detail. Hopefully, it's a detail that every implementation would include, but the API doesn't enforce it. OTOH, I wouldn't be in favor of requiring TilesContext *and* Locale as that would be redundant. So, in the end, I don't have a problem with the patch as it stands. I'd prefer it if we could have some way to better enforce Locale processing at the API level, but I can live with it as it is. The biggest benefit I see is that some of that TilesUtil stuff is moved into the factory. Can you make it work with the latest Tiles code and commit it? If we end up not liking it we can always back it out. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] Classpath Configuration
On Oct 11, 2006, at 2:44 PM, David H. DeWolf wrote: So are you suggesting that we: 2) Update the UrlDefinitionsFactory to load the resource itself. 3) Create a new ClasspathDefinitionsFactory Some variation of one of the above. Ideally, we'd like to do it without changing any code :-) My thinking was to see if it could be done by changing TilesListener and/or TilesUtil and keep using the UrlDefinitionsFactory. Barring that, we could implement a ClassloaderDefinitionsFactory that loads from the classpath. The latter has the disadvantage (maybe) of having to choose one or the other. If we take that direction you can't do both servlet context and classpath. If the UrlDefinitionsFactory can be made to work, it would allow you to do both. I'm not sure if that's a good thing or a bad thing. Maybe you should be forced to choose. Doing #3 above will require a customized TilesListener anyway. I don't see how the same code could be used to invoke both types of DefinitionsFactories. So I'd prefer if it could be done using the current UrlDefinitiionsFactory and modify TilesListener to be able to get URLs from both ServletContext and the Classloader. If that can't be done, then I'd support option 3. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] Classpath Configuration
On Oct 11, 2006, at 1:12 PM, David H. DeWolf wrote: I'd like to implement the ability to load tiles definitions from the classpath in addition to from the servlet/portlet context. I'm curious about implementation choices: 1) Add the support to the current ServletTilesContext and PortletTilesContext through a standard base class and/or ResourceLoader. This is probably the way to go if class loader loading of definitions will be considered a standard feature. It would be my first choice. I like the idea but I think you're on the wrong track to look at TilesContext. TilesContext is just a generic interface for storing information about the context in which Tiles is running. Some type of web context is assumed. The primary interfaces for creating Tiles definitions are org.apache.tiles.DefinitionsFactory and org.apache.tiles.DefinitionsReader. The DefinitionsFactory is responsible for storing the sources where definitions come from and storing definitions. DefinitionsReader is responsible for reading definition data in a specific format from each source and returning them as ComponentDefinition objects. So, for example, we have an UrlDefinitionsFactory that stores a list of URLs as the sources for definitions. We also have the DigesterDefinitionsReader that expects the sources to point to XML files and can read XML definitions. If you wanted to store your definitions in a database you might write a JDBCDefinitionsReader that would read definitions from a database. If you want to store XML files on the classpath you might write a ClassloaderDefinitionsFactory that works with the classloader to load definitions files. Or... you might find that you can do it with existing code by using the UrlDefinitionsFactory and getting the URLs from the classloader instead of from servlet context. In this case you might have to create a new TilesListener that reads a classloader instead of or in addition to the servlet context. These things should work interchangeably. The Reader shouldn't care how definitions were loaded. It only works with definitions stored in a particular format. Likewise, the Factory shouldn't care what format the definitions are in. It simply knows where to get them. No specific reader implementation or factory implementation should have any dependency on the other. If they do, then we haven't implemented it correctly. Additionally, what are people's thoughts about wildcard handling for the resource definitions files. Is this a feature others are interested in? This sounds like a good idea also. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] Tiles "controllers" (WAS: Re: [tiles2] Some words about proposed changes)
On Oct 10, 2006, at 3:31 AM, Antonio Petrelli wrote: Last night (I should sleep, I know :-P ) I thought that "named preparers" could be introduced. I mean, instead of specifying the prepared class directly, they can be configured in tiles-defs.xml through a element (and eventually in a tag for page-scoped preparers) just like definitions are configured, then a "preparer" attribute could be added to and (and probably too) specifying the name and not the class. How does it sound to you? Is there any benefit to this other than not having to type the class name multiple times? If not, I'm not sure I see a big advantage, but I'm not against the idea. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] Separate attribute handling from
Yeah, I can accept that definition. Greg On Oct 10, 2006, at 1:40 AM, Antonio Petrelli wrote: Greg Reddin ha scritto: I don't know. Having used Tiles for a while, I'm used to the way things are. It doesn't bother me to use the same overloaded tag in two different ways. I'm not sure if it's confusing to the users or not. I don't know if it's the same for you, but in my mind a "tile" can be a page, a definition or a string. A layout page is like a tile pattern, tags are like tile gaps, and the surrounding HTML code is made of tile joints... Sorry for this building analogy :-) What I mean is that the concept of attribute is that it is so different from the "tile" analogy, i.e. you put a tile (definition, page, string) where there is a tile gap (attribute). I hope that I have been clearer now :-) Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] Separate attribute handling from
Maybe we need and to handle the 2 types specifically instead of one to handle them generically. I don't know. Having used Tiles for a while, I'm used to the way things are. It doesn't bother me to use the same overloaded tag in two different ways. I'm not sure if it's confusing to the users or not. I guess if the logic is already split up by if statements it makes sense to just move it into separate classes with their own name. The only issue is that right now I can use to generically include a named fragment. The fragment could be an attribute of the "current" definition or it could be a completely independent definition. Part of the problem is with the definition of a tile. Right now a "tile" can be any of three things, pretty much handled generically by the tag. Those three things are: * A JSP page. * An attribute of the current Tiles definition. * Another Tiles definition. Maybe we need to call the definition a "tile", an attribute an attribute, and a page a page. OTOH, maybe it's good practice to keep the ambiguity and call everything a tile. I can see benefits and drawbacks to both approaches. Keeping it generic gives Tiles a lot of flexibility. Requiring more specificity makes it easier for newbies to get used to. Could/Should we do both (i.e an tag for generic inserts and , , and tags for specificity)? Greg On Oct 6, 2006, at 2:35 AM, Antonio Petrelli wrote: Re-Re-Hi again I know I am bugging you again but I have another idea. Personally I don't like using the same tag to define attributes in a layout page and to insert templates/definitions/ strings: I think the concept of attribute is separated from the rest (it is somewhat like specified a "setXXX" statement in a Java Bean). Moreover if you take a look at InsertTag, attribute handling code is almost separated (except of a set of "if-else if" statements) from definition and template handling. I think that a tag could be created: I think that this way the code of InsertTag (and the future AttributeTag) will be much simpler, and the resulting application code will be more intuitive. What do you think? Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] GetTag vs. InsertTag
On Oct 6, 2006, at 6:37 AM, Antonio Petrelli wrote: Hmm, I can't find any of my examples of using getAsString but I thought I'd done it like this: name="tilte"/> or something like that. I would be perfectly fine if I could use in that way if getAsString goes away. So I guess my answer to your question is yes :-) Aarghh! I was wrong, is not the same as because it should be an attribute (type="attribute") of type "string": yuck two types! At this point I think we should not remove but maybe we can rename its class, GetAttributeTag, to GetAsStringTag. Is it ok with you? Yeah, I'm ok with that. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] Tiles "controllers" (WAS: Re: [tiles2] Some words about proposed changes)
On Oct 6, 2006, at 2:27 AM, Antonio Petrelli wrote: Greg Reddin ha scritto: Here's what I envision for the controller: I don't think it would really be used to change the destination of the response. I don't see the controller as being analogous to a Struts action even though it could be used in that way. If I wanted the controller to be used as a "controller" in the MVC sense of the word (IOW to select a destination) I'd want it to return something like actions do in Struts, WebWork, and JSF. I've always used the controller like a JSP tag. I use it to implement code that needs to reside in the view layer (or code that needs to be called from the view layer) and as a way to keep from writing scriptlet code in my JSPs. Uh I see, I think it's time to resurrect controllers (I think it's needed only in the TLD). Now what about their name? I think we still want to support it in the DTD for the tag. When I've used controllers I've always declared them in the tiles-defs.xml file. Possible names could be: * Controller for the class (or maybe TilesController) - controllerClass and controllerUrl for tag attributes Well, it's the controllerUrl I have the most trouble with. I don't have any problem with declaring a class to be executed to prepare the view. But an URL? An URL will always resolve to something - return a response - and I don't think these view preparers should return anything or resolve anything. They should simply be capable of manipulating the context - preparing the context for the view (IMHO). * ViewPreparer (or TilesPreparer) for the class - preparerClass and preparerUrl and for the tag attribute (thanks Nathan!); I think I like ViewPreparer the best. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] GetTag vs. InsertTag
On Oct 5, 2006, at 10:50 AM, Antonio Petrelli wrote: Greg Reddin ha scritto: On Oct 5, 2006, at 2:46 AM, Antonio Petrelli wrote: Greg Reddin ha scritto: But don't forget about the tag as well. It's semantics are quite different from . How would it be affected if we removed the GetTag? I forgot a thing: uses GetAttributeTag that does not extend neither GetTag nor InsertTag. Anyway I still think also this tag can be removed, and to use I'm +1 for that as long as getAsString works the same as insert type="string'. Well not exactly... puts an attribute just like calling .toString method. Currently if an attribute is not a string and you specified type="string" raises an exception. Should we change the behaviour of InsertTag or stick with ? Hmm, I can't find any of my examples of using getAsString but I thought I'd done it like this: > or something like that. I would be perfectly fine if I could use in that way if getAsString goes away. So I guess my answer to your question is yes :-) Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] Some words about proposed changes
On Oct 5, 2006, at 9:53 AM, Antonio Petrelli wrote: * The controllers were added to allows stand alone use of tiles to be able to do some kind of computation associated to the tiles. When used with Struts, there is a redundancy (with the use of actions), but when used alone, the controller mechanism is very useful to separate view rendering from controller business The problem with Tiles controllers is that the controller is not able to choose between different destination pages. It misses an important part of a controller: the dispatcher. But using a normal url as a template (or tile :-) ) it can do both calling the model and dispatching. If you download the latest version from SVN, there is a test with a simple servlet that includes a (fixed for the moment) JSP page. And I think that including a Controller in a View layer technology is not a good idea. Here's what I envision for the controller: I don't think it would really be used to change the destination of the response. I don't see the controller as being analogous to a Struts action even though it could be used in that way. If I wanted the controller to be used as a "controller" in the MVC sense of the word (IOW to select a destination) I'd want it to return something like actions do in Struts, WebWork, and JSF. I've always used the controller like a JSP tag. I use it to implement code that needs to reside in the view layer (or code that needs to be called from the view layer) and as a way to keep from writing scriptlet code in my JSPs. It just so happens that the controller API gives you indirect access to the request and response objects so you could use them to include or forward or write directly to the response and all the other stuff you can do there. But I'd not recommend the controller be used in this way. I would use the controller to manipulate the TilesContext and the JSP contexts, but not to actually "do anything" with regards to changing the destination. In today's world if I was writing a Struts app with Tiles I would try to use JSTL, EL, custom tags, (or in JSF, action listeners, etc). to do things I did in the past with controllers. But I can still see circumstances where I might want a controller instead. Think about this: Tiles can be used for page composition outside of any MVC framework. In that sense it's kind of like a portlet container. (In fact I think that's how Cedric envisioned it before JSR-168 came about). So you can compose pages out of JSP fragments and populate each fragment with a controller that is executed before the fragment is processed and included. I actually have written a couple of small webapps that use Tiles in this way and see it as a powerful feature. I think we should retain the controller for Tiles definitions (not sure about the insert tag). I also think we should document the fact that you can get yourself into all kinds of trouble by making improper use of the request and response APIs from within the controller. Thoughts? Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] Some words about proposed changes
On Oct 5, 2006, at 8:45 AM, Cedric Dumoulin wrote: I just came across some of the mails about Tiles2. First, I am very glad that someone has the time to let Tiles evolve. But, I am a little bit disappointed about how the proposed Tiles API evolved. I'm glad you're speaking up and watching what's going on. In many cases I've been uneasy about the changes I've made simply because I'm not sure I understood the original intent of things I've removed or modified. I'm glad you're still around :-) * was changed to - because we mainly say that we want to insert something So, have we come to the conclusion that Insert will stay and Get will go? I'm comfortable with that approach at this point. * Attributes "template=" and "component=" were changed to "page=" - because we specify the page to insert. Tiles is more than a templating mechanism, and the inserted page is not necessary a template :-). Maybe we can use "tile=" now that tile is a very well established name. The only problem I have with "tile" is that I would tend to think of a "tile" as a named definition or something. More often than not I think of inserting a tile as inserting a definition by name i.e. tile="headerTile" rather than as inserting a page i.e. tile="/ headerTile.jsp". I like using "template" on the definition tag because, on a definition, it seems like the "page" really is a template. It's a page to which parameter values (or attribute values) will be applied when it is invoked. But I guess you could see any JSP page as being that way. So there's only a very subtle difference between a page that is a template vs. a page that is not a template. It gets really crazy if you think of it this way: The only time a JSP page is not a template is if it *only* contains template text. Yuck :-) In the end I'm ok with using "tile" if that's what everybody else wants. However, if we go this route I think we need to document somewhere "What is a tile?" It can be a page. It can be a template. It can be an attribute, etc. After thinking about it a bit I'd *really* prefer we use "template" to define a page on a tag and use "page" to define it everywhere else ( and ). To me, that's the most clear. But I can go either way. * The controllers were added to allows stand alone use of tiles to be able to do some kind of computation associated to the tiles. When used with Struts, there is a redundancy (with the use of actions), but when used alone, the controller mechanism is very useful to separate view rendering from controller business I'll respond more fully to this in response to Antonio, but in essence I agree with you about this. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] GetTag vs. InsertTag
On Oct 5, 2006, at 2:46 AM, Antonio Petrelli wrote: Greg Reddin ha scritto: But don't forget about the tag as well. It's semantics are quite different from . How would it be affected if we removed the GetTag? I forgot a thing: uses GetAttributeTag that does not extend neither GetTag nor InsertTag. Anyway I still think also this tag can be removed, and to use I'm +1 for that as long as getAsString works the same as insert type="string'. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] GetTag vs. InsertTag
On Oct 4, 2006, at 11:48 AM, Wendy Smoak wrote: On 10/4/06, Antonio Petrelli <[EMAIL PROTECTED]> wrote: I think that is the most used, even I wrote some tests (in the test webapp) using and I am used to write only But we are cleaning Tiles from the unnecessary and I like more (going against my own interests :-) ), simply because it is the opposite of , I think it's more intuitive. I'd lean towards keeping because it is widely used. 'Put'ting something in the context, then 'insert'ing it into a page make sense to me. Unfortunately, I don't have time right now to dig into the code and figure out what's going on internally, but at a glance I think I agree with Wendy. To me says "insert this tile or attribute right here on my page" whereas would say "get a tile or attribute from context and let me do something with it later." But don't forget about the tag as well. It's semantics are quite different from . How would it be affected if we removed the GetTag? I'm sorry I haven't had any time to help out with Tiles issues lately. My day job has been in a whirl and I've been "forced" to dive into JSF, MyFaces, and Facelets. I promise I fully intend to come back, hopefully with a better understanding of where tiles fits into the JSF landscape. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles2] Removal of controllerClass and controllerUrl
On Oct 2, 2006, at 7:12 AM, Antonio Petrelli wrote: Hello everybody :-) In InsertTag the "controllerClass" and "controllerUrl" have been removed, I guess according to this JIRA issue: http://issues.apache.org/struts/browse/SB-21 I don't know if it's correct, because, as it is said in taglibs docs, the class or the URL is called immediately before rendering: http://struts.apache.org/1.x/struts-tiles/tagreference.html#insert It looks like I removed them in revision 419638. But I can't tell why specifically I removed those from the commit message. At first glance it seems like an error. I'll take a few minutes today and check into it to see if that's what I really meant to do. Can you specify a controllerClass and/or controllerUrl on the tag? If so, maybe I intended for the tag to not support it. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (SB-21) Determine which tag attributes should be removed
On Sep 27, 2006, at 6:44 AM, Antonio Petrelli (JIRA) wrote: Removed "direct" attribute from and , because to reproduce the same result it is possible to use type="string". Added FAQ with the explanation of the removal. That answers my question. I'm cool now. Thanks, Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r450403 - in /struts/sandbox/trunk/tiles/tiles-core/src/main: java/org/apache/tiles/taglib/PutTag.java resources/META-INF/tiles-core.tld
Sorry to keep questioning your commits, but I just want to clarify one thing: The purpose of the direct attribute is to allow you to insert HTML directly as the value of the tile, perhaps like this: direct="true"/> as opposed to Also you are supposed to be able to use the body of the tag as the value: something If this type of behavior is still supported by the removal of the direct attribute then I am +1 for this change. Thanks, Greg On Sep 27, 2006, at 6:43 AM, [EMAIL PROTECTED] wrote: Author: apetrelli Date: Wed Sep 27 04:43:33 2006 New Revision: 450403 URL: http://svn.apache.org/viewvc?view=rev&rev=450403 Log: SB-21 Removed "direct" attribute from and Modified: struts/sandbox/trunk/tiles/tiles-core/src/main/java/org/apache/ tiles/taglib/PutTag.java struts/sandbox/trunk/tiles/tiles-core/src/main/resources/META- INF/tiles-core.tld Modified: struts/sandbox/trunk/tiles/tiles-core/src/main/java/org/ apache/tiles/taglib/PutTag.java URL: http://svn.apache.org/viewvc/struts/sandbox/trunk/tiles/tiles- core/src/main/java/org/apache/tiles/taglib/PutTag.java? view=diff&rev=450403&r1=450402&r2=450403 == --- struts/sandbox/trunk/tiles/tiles-core/src/main/java/org/apache/ tiles/taglib/PutTag.java (original) +++ struts/sandbox/trunk/tiles/tiles-core/src/main/java/org/apache/ tiles/taglib/PutTag.java Wed Sep 27 04:43:33 2006 @@ -71,11 +71,6 @@ private Object value = null; /** - * JSP Template compatibility. - */ -private String direct = null; - -/** * Requested type for the value. */ private String valueType = null; @@ -113,7 +108,6 @@ attributeName = null; valueType = null; -direct = null; value = null; role = null; body = null; @@ -179,14 +173,6 @@ } /** - * Set direct. - * Method added for compatibility with JSP1.1. - */ -public void setDirect(String isDirect) { -this.direct = isDirect; -} - -/** * Set type. */ public void setType(String value) { @@ -243,21 +229,16 @@ // Test body content in case of empty body. if (body != null) { realValue = body; +valueType = "string"; } else { realValue = ""; } } // Is there a type set ? -// First check direct attribute, and translate it to a valueType. -// Then, evaluate valueType, and create requested typed attribute. -// If valueType is not set, use the value "as is". -if (valueType == null && direct != null) { -if (Boolean.valueOf(direct).booleanValue() == true) { -valueType = "string"; -} else { -valueType = "page"; -} +// If valueType is not set, defaults to "page". +if (valueType == null) { +valueType = "page"; } } @@ -321,7 +302,7 @@ // Do we need to evaluate body ? if (value == null) { -return EVAL_BODY_TAG; +return EVAL_BODY_BUFFERED; } else { // Value is set, don't evaluate body. return SKIP_BODY; Modified: struts/sandbox/trunk/tiles/tiles-core/src/main/resources/ META-INF/tiles-core.tld URL: http://svn.apache.org/viewvc/struts/sandbox/trunk/tiles/tiles- core/src/main/resources/META-INF/tiles-core.tld? view=diff&rev=450403&r1=450402&r2=450403 == --- struts/sandbox/trunk/tiles/tiles-core/src/main/resources/META- INF/tiles-core.tld (original) +++ struts/sandbox/trunk/tiles/tiles-core/src/main/resources/META- INF/tiles-core.tld Wed Sep 27 04:43:33 2006 @@ -240,17 +240,6 @@ - direct - false - false - - - - - type false false @@ -329,19 +318,6 @@ Element value. Can be a String or Object. ]]> - - - direct - false - false - - - type - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r449993 - /struts/sandbox/trunk/tiles/tiles-core/src/main/resources/META-INF/tiles-core.tld
On Sep 26, 2006, at 10:16 AM, Antonio Petrelli wrote: Maybe there is some misunderstanding, only "scope", "flush", "type" and "direct" (the latter will be removed anyway, AFAIK) have false. The attributes you mentioned can be used with EL... Wow, you're right. I was looking at it backwards :-) Sorry, I've had a long month this week Thanks, Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r449993 - /struts/sandbox/trunk/tiles/tiles-core/src/main/resources/META-INF/tiles-core.tld
I'm not so sure we want to restrict all these things. I'm not terribly concerned about name. classname, I can live with. I feel pretty strongly that I want to be able to use EL to define value. I can think of circumstances where I would want to define id using EL. And it seems reasonable to be able to evaluate file with EL. Can you give me your reasoning for wanting to restrict them from being used with EL? Greg On Sep 26, 2006, at 6:26 AM, [EMAIL PROTECTED] wrote: Author: apetrelli Date: Tue Sep 26 04:26:48 2006 New Revision: 449993 URL: http://svn.apache.org/viewvc?view=rev&rev=449993 Log: SB-23 Specified true on all attributes that are not "scope", "type", "flush", "direct" that, IMO, don't need to be evaluated by EL. Modified: struts/sandbox/trunk/tiles/tiles-core/src/main/resources/META- INF/tiles-core.tld Modified: struts/sandbox/trunk/tiles/tiles-core/src/main/resources/ META-INF/tiles-core.tld URL: http://svn.apache.org/viewvc/struts/sandbox/trunk/tiles/tiles- core/src/main/resources/META-INF/tiles-core.tld? view=diff&rev=449993&r1=449992&r2=449993 == --- struts/sandbox/trunk/tiles/tiles-core/src/main/resources/META- INF/tiles-core.tld (original) +++ struts/sandbox/trunk/tiles/tiles-core/src/main/resources/META- INF/tiles-core.tld Tue Sep 26 04:26:48 2006 @@ -140,7 +140,7 @@ name true - false + true
Re: svn commit: r449993 - /struts/sandbox/trunk/tiles/tiles-core/src/main/resources/META-INF/tiles-core.tld
On Sep 26, 2006, at 10:32 AM, Antonio Petrelli wrote: Sorry, I've had a long month this week Just an OT question :-) , what does this turn-of-speech mean? The last week has been so crazy it feels like it's been a month :-) I assume you've heard the phrase "It's been a long day" or "... a long week" or "... a long month", which means, of course that the day, week, or month has been difficult. Well, saying "it's been a long week" is not enough. It's been such a long week that it feels like it's been a month :-) Hope that makes sense. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Tiles2] Publishing Snapshots
Sorry for my ignorance on this, but do we have to manually publsih a SNAPSHOT or is it published automatically through the nightly build? There have been a lot of fixes of late and users might want to download a new snapshot build. Thanks, Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Semi-OT] Possible Scopes incubation (WAS: Re: [jira] Created: (STR-2939) Provide a conversation scope (syn: Flash scope, dialog scope) object to store data between requests.)
If you built scopes would it require the incubator to bring it in? If you built all the code from scratch couldn't you just import it into the sandbox? Or would we want to bring it through the incubator to ensure there are no IP issues? The LGPL parts would probably need to be factored out. I'm really not sure of the protocol here. If you have something valuable to contribute and you're already a committer, it would be nice if you didn't have to go through the Incubator. But maybe it's better to do so just to avoid IP issues. BTW, this is not an endorsement or otherwise of Scopes. I don't even know what it is :-) Greg On Aug 30, 2006, at 3:45 AM, Antonio Petrelli wrote: Michael Jouravlev ha scritto: Hi Antonio, I looked through your code, it is quite clear, so I started pulling needed stuff from your library and sticking it into Struts. I also want this scope to be available for ActionForms in action mapping definition, and for errors/messages. One of the reasons for which I built Scopes was the possible use in every layer of the web application, even in the Model, e.g. imagine the use of Conversation Scope with Spring scopes. So for the moment you are doing the right thing pulling the code directly, but now I am guessing if it is the case of incubating Scopes, or probably putting it in the sandbox under the Struts umbrella, if it raises attention by this community. But I think that there are two possible barriers to incubation: - Scopes has a lonely developer for the moment (me :-) ) - A (small but interesting) part of Scopes (the "window" scope) is based on a LGPL library. What do you think? Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles] Errors in tiles-test webapp
On Aug 22, 2006, at 12:17 AM, Wendy Smoak wrote: The app starts and deploys, however - the 'Test Put Tag' link results in a blank page, and - the 'Test Definition Tag' link throws an exception: org.apache.jasper.JasperException: /testdef.jsp(3,0) According to the TLD or the tag file, attribute name is mandatory for tag definition Is it possible the app was not updated after the most recent round of changes? Nope, those errors were occurring before the last round of changes. I haven't yet figured out what's causing them, but they are known errors. Does it make the build fail? Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles] Tiles 2 DTD
On Aug 4, 2006, at 9:35 PM, Wendy Smoak wrote: Since Tiles 2 is in the sandbox, it's the easiest place to experiment. :) Works for me :-) I've added the config to the tiles-core pom, and re-published the site. Here's the generated output: Wow, I like the documentation. That's cool. I haven't had time to drill into it and look for correctness and whatnot, but I like it so far. What is the status of a DTD for Tiles 2? We have 1.1 and 1.2 versions in Tiles 2. (Which is odd because there was never a 1.2 DTD for Struts Tiles.) I'm not sure where all that came from. I actually don't know that it's changed any - though I think it probably needs to. I'm somewhat intrigued by Antonio's IoC for the view message a couple of days ago. If we start to push Tiles in that direction it may also affect the DTD. I know there's a couple of things we need to look at (like the beanName/beanScope pair scattered about). Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles] Test failure in tiles-core
Yep I'm getting it too. Antonio, did you perhaps forget to check something in? Greg On Aug 1, 2006, at 10:53 PM, Wendy Smoak wrote: Is anyone else seeing this in sandbox/tiles/tiles-core ? -- - Test set: org.apache.tiles.TestTilesServlet -- - Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.234 sec <<< FA ILURE! testCustomizedInitTilesServlet(org.apache.tiles.TestTilesServlet) Time elapsed: 0.015 sec <<< FAILURE! junit.framework.AssertionFailedError: MockComponentDefinitions not used. expecte d:<3> but was:<2> at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:282) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:201) at org.apache.tiles.TestTilesServlet.testCustomizedInitTilesServlet(Test TilesServlet.java:103) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r427541 - /struts/sandbox/trunk/tiles/tiles-core/src/main/java/org/apache/tiles/definition/ComponentDefinitionsImpl.java
On Aug 1, 2006, at 6:39 AM, [EMAIL PROTECTED] wrote: Object attrValue = attr.getValue(); if (attrValue instanceof ComponentDefinition) { retValue = (ComponentDefinition) attrValue; -} else { // It must be a string +} else if (attrValue instanceof String) { retValue = this.getDefinition((String) attr .getValue()); } @@ -239,12 +239,12 @@ */ private ComponentDefinition getDefinitionByAttribute( ComponentAttribute attr, Locale locale) { -ComponentDefinition retValue; +ComponentDefinition retValue = null; Object attrValue = attr.getValue(); if (attrValue instanceof ComponentDefinition) { retValue = (ComponentDefinition) attrValue; -} else { // It must be a string +} else if (attrValue instanceof String) { retValue = this.getDefinition((String) attr .getValue(), locale); } Thanks for doing this :-) It's nice to see someone else committing. In the above code do you think it's ok to return null in the unlikely event attrValue is not a String? Oe should we do an else that throws an exception or something? Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Standalone Tiles] Applying patches
On Jul 28, 2006, at 1:42 AM, Antonio Petrelli wrote: P.S.[OT]: New mail address, eh? Will that website be your music site? Actually that's always been my address. I just forward my apache acct there. It's kind of a pseudo side business of mine. Mostly a hobby, but once a year or so, somebody pays me to mix for them :-) Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New Struts Committer: Antonio Petrelli
Please join us in welcoming Antonio Petrelli as a Struts committer. Antonio has been an active contributor on the mailing lists for quite some time and has contributed patches and ideas to the development of Tiles. We look forward to Antonio's contributions and his ability to commit his own patches :-) Welcome Antonio! PMC vote: 7 +1 Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Portlet App and Ant (was Re: Would like to remove Ant build from Struts 2)
On Jul 24, 2006, at 9:47 AM, tm jee wrote: About the ant build that creating a skeleton for various portlet container, what if we build a maven arcetype specific for each of the portlet container? Maybe, mvn archetype:create .. portlet-liferay-archetype-starter will create a template/skeleton for liferay portal, just like what we did for struts2-archetype-starter. What do you guys think, feasible? To me this is no different than building maven archetypes to deploy a Struts app into specific app servers. Do we want to provide tools with the framework to deploy apps into Tomcat, JBoss, WebLogic, etc. or do we just use tools provided by the server vendors and provide documentation to help people use them? Honestly, I don't know what the WebWork approach has been in the past. I think with Struts, we've just provided helper documentation for those kinds of things. With portlets I'm learning there are multiple levels of integration. There are "bridges" that help you turn your app into a portlet: i.e. a Struts-portlet bridge, a JSF-portlet bridge, etc. That's what the MyFacesGenericPortlet class is and the Apache Portals Bridges subproject[1]. Then, there's portlet integration with various portal vendors. JBoss, Liferay, Jetspeed, BEA, IBM, Oracle, etc. all have their own deployment strategies. (Sorry if I'm bombarding you with information you already know. I'm just now going deep with portlets and portals). With Liferay, for example, you create a liferay- portlet.xml and a liferay-display.xml and they provide an ant script that turns your .war file into a Liferay portlet and hot deploy it. With JBoss (IIRC) you create a jboss-portlet.xml and drop your .war file in the right directory. I can't remember the process with Jetspeed. And I haven't tried any of the others. Given what I've learned so far, my preferred approach would be to write a generic bridge to ensure that Struts apps could work within portlets with as little difficulty as possible. I'm getting closer to being able to just drop a JSF app into a portal using the vendor- provided deployment strategy. That would be the ideal for me. I never (or very rarely) will have to write a "portlet" if I can help it. I just write to my favorite framework and I can deploy it as a web app or as a portlet. Thoughts? Greg [1] http://portals.apache.org/bridges/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Portlet App and Ant (was Re: Would like to remove Ant build from Struts 2)
On Jul 22, 2006, at 7:29 PM, Ted Husted wrote: What about this? * http://www.twdata.org/backups/WW/how-to-build-the-portlet-war-for- a-specific-portal-server.html Meanwhile, what's involved in setting up Tomcat 5.5. for portlets? It's a bit more involved than just getting portlets to work in Tomcat. You have to install a portal server like Liferay, Jetspeed, or JBoss Portal. Liferay can be downloaded as a bundle that includes Tomcat. Jetspeed portals can be deployed into Tomcat using Maven 1 (They may have upgraded their scripts to m2 or ant. There was some talk about that but I'm not real sure where it went.) JBoss Portal comes with JBoss, of course. Liferay also has an ant portlet deployment script that you can use. It seems to me that portlet deployment is more of a function of the portal server than the framework. Is this question related to deploying a Struts 2.0 app as a portlet? If so, maybe the best thing to provide is a portlet wrapper that can work with an s2 app (similar to MyFacesGenericPortlet for MyFaces). Then let the portal vendors provide the deployment script. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles] beanName and beanScope unveiled
On Jul 12, 2006, at 10:06 AM, Antonio Petrelli wrote: Some time ago we were wondering what's the use of "beanName" and "beanScope" attributes in tag. The answer came from some users: http://www.mail-archive.com/user%40struts.apache.org/msg48310.html http://www.mail-archive.com/user%40struts.apache.org/msg48459.html Yep I was watching that thread. If you've followed the commit messages I completely removed those attributes from the TLD. It wouldn't be too difficult to add them back if we need to. 1) Both of those users need "beanName" and "beanScope" implemented in tiles-defs.xml, because they seem to be not implemented according to the DTD. But in Cedric Dumoulin's site: http://www2.lifl.fr/~dumoulin/tiles/ it says: Now, are these attributes implemented or not? They are not available in the DTD right now. I'm not sure what the history is. Maybe they were there and got removed. I'm not sure. 2) If it should be implemented, is it best to create an issue to Standalone Tiles or Struts-Tiles? Hmmm. That I don't know. File it in Struts-Tiles for now. It will probably apply to both. Greg P.S.: Siamo i campioni del mondo! Well, if Babel Fish got it right, congratulations! I tuned in right before Zidane got the card. I hated that it had to end in PKs but oh well - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts1] 1.3.5 - "Embedded" Tiles
On Jul 11, 2006, at 5:51 PM, Wendy Smoak wrote: On 7/11/06, Ted Husted <[EMAIL PROTECTED]> wrote: For this version, I'd like to cut to the chase and treat Tiles as bundled component, like the Validator. I don't know if we have the code in there to use it standalone or not, but even if we do, we should refer people to Tiles 2 for that sort of thing. Fine with me, but right now there is no documentation in the sandbox for Tiles 2. We'll have to come up with at least a simple configuration example. (Greg? How do you use this thing?!) I had intended to finish out the 1.x documentation in such a way that it could be ported to 2.x but I ran out of time. The existing doc is high-level enough that it still applies to both - except the reference to TilesServlet, which only applies to 2.0 You're welcome to make changes to it as needed. Also, I'm willing to either answer questions or help flesh it out further. My time is just almost nill right now :-( Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Rename Struts Action as Struts
On Jun 30, 2006, at 9:58 AM, Ted Husted wrote: Now, in place of "Tapestry4" and "Tapestry5". we now have "struts-action" and "struts-action2" * http://svn.apache.org/viewvc/struts/ which we could just rename to "struts1" and "struts2". That sounds good to me. I was just asking if we wanted to make the reference "s1" and "s2". This works but I prefer the more explicit "struts1" and "struts2". I can live with it either way. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts really need two frameworks? (long)
On Jun 21, 2006, at 8:31 PM, Ted Husted wrote: We like to chatter about what's best for Struts, or what Struts is, but I think the key question is what's Shale, and what's best for Shale? I remain concerned that, after two years on a greenfield, there has not been a GA release of Shale. I have to wonder if keeping Shale here is stunting the community's growth. We've heard from Craig, but in order to make any kind of decision, I'd have to know how the other people working on Shale feel. Unfortunately, I don't have time to think through my response well enough right now, so if this seems disjointed, please forgive me. I'm not working directly on Shale (yet) but I am holding up a GA release :-) As I understand it one of the big reasons Shale is not to GA yet is because it can't go to GA until Tiles does. While it's waiting for Tiles, new innovations are happening that may be further holding up the release, but I've read on this list that Shale can't go GA until Tiles goes GA. I'm not sure if that's a dependency that can or should be removed. I see the advantages Shale brings to the table when working with JSF and I want it to succeed. The problem with keeping it here is that it may be perceived as a tagalong library to Struts no matter how we try to present it. The problem with moving it is that we have to set up all the infrastructure to support it. Not just the bureaucracy of its own TLP and PMC, but the spreading thinner of the people involved. For example, how many Apache projects can somebody like Wendy support before she implodes :-) Is it easier for her to add value to Shale's capabilities here than if Shale moved to a TLP? To clarify, if we build in improvements to Struts project management then we have to copy those improvements to Shale if it lives on its own whereas now we can just inherit them. The advantage of an umbrella project is that you don't have to copy things :-) And committers can migrate around to whatever their current needs are without having to switch PMC's or figure out which mailing list to post to. I'm conflicted as to the best approach. Living on its own will give Shale room to grow. Living here makes it easier for those of us who are already here to participate. I'll be involved in both as much as possible either way. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles] DTD version and cleanup
On Jun 17, 2006, at 10:41 PM, Wendy Smoak wrote: In the sandbox, Tiles has tiles-config_1_1.dtd and tiles- config_1_2.dtd. After the "Tiles 2.0" thread, I'd suggest changing to just tiles- config_2_0.dtd. And along the lines of SB-21 cleaning up the TLD, it looks like a few things can be removed from the DTD: ContentType page (use template) definition (use template) (I'm not certain about this, but I think page/definition/template are the same.) component-definitions (use tiles-definitions) definition page (use path) template (use path) add direct (use type=string) put direct (use type=string) content (use value) If there are no objections, I'll open an issue for it. I think you are correct. Please do. Thanks, Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tiles] Version 2.0?
+1. I think that solves a lot of things. Greg On Jun 17, 2006, at 6:14 PM, Wendy Smoak wrote: In another thread, On 6/14/06, Greg Reddin <[EMAIL PROTECTED]> wrote: On Jun 14, 2006, at 11:21 AM, Joe Germuska wrote: > However, I realize as I write this that saddling Standalone Tiles > with that kind of weight is wrong. SAT is essentially a 2.0 > release, and should clean up all these kinds of things (and I too > find the Tiles API overly cluttered, so i'm totally in favor of > these kinds of changes...) I agree that ST is basically a 2.0 version. I aim to clean it up as much as possible. I just hope we don't lose the user base in the process. Hmmm... "Tiles 2.0" ? I like it. :) No need to state the obvious -- it's clearly standing alone, since it isn't packaged with Struts Action and has no dependencies on it. "Tiles" vs. "Struts Tiles" should be enough to differentiate them, if we're consistent. Thoughts? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Standalone Tiles] Changing the Semantics of the InsertTag
On Jun 14, 2006, at 11:21 AM, Joe Germuska wrote: At 9:00 AM -0700 6/14/06, Wendy Smoak wrote: On 6/14/06, Joe Germuska <[EMAIL PROTECTED]> wrote: Would you consider some kind of compatibility mode? That is, before you remove support for these, could there be a way for people to configure things for a more strict or more compatible evaluation, to ease migration? It seems like the closest you can get to deprecation warnings in tag libs/JSPs. Rather than keep these things around in Standalone Tiles, I think the responsibility for 'deprecation' warnings falls to Struts Action. but in Struts action, it would only be documentation, while in tiles, it could be done in a way that you could transition in code. However, I realize as I write this that saddling Standalone Tiles with that kind of weight is wrong. SAT is essentially a 2.0 release, and should clean up all these kinds of things (and I too find the Tiles API overly cluttered, so i'm totally in favor of these kinds of changes...) Agreed. Part of the reason Tiles is in the shape it is in is for the sake of compatibility. The problem is I don't think the story was told very well. So, in a Java class you deprecate and say "use this instead" but with Tiles the "use this instead" message was lost. The result is you have people out there doing all kinds of things that were "accidentally" supported. I agree that ST is basically a 2.0 version. I aim to clean it up as much as possible. I just hope we don't lose the user base in the process. My other comment was kind of reflexive.I suppose it could be applied to struts-tiles -- or maybe you mean that the responsibility falls to the struts-tiles component of struts-action? That's the way I took it (struts-tiles). And maybe that's a compatibility API. We wrap a struts-tiles compatibility layer around standalone Tiles, deprecate it and add notes to the taglib doc. Cut a release, then remove it and cut another release :-) Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Standalone Tiles] Changing the Semantics of the InsertTag
On Jun 14, 2006, at 11:00 AM, Wendy Smoak wrote: On 6/14/06, Joe Germuska <[EMAIL PROTECTED]> wrote: Would you consider some kind of compatibility mode? That is, before you remove support for these, could there be a way for people to configure things for a more strict or more compatible evaluation, to ease migration? It seems like the closest you can get to deprecation warnings in tag libs/JSPs. Rather than keep these things around in Standalone Tiles, I think the responsibility for 'deprecation' warnings falls to Struts Action. Once we know which attributes are going away, if we start warning people in 1.3.x it won't be a surprise. But that's assuming SAF1 intends to switch to Standalone Tiles behind the scenes at some point. George and Greg's exchange assuming the presence of EL points to moving Standalone Tiles to a Servlet 2.4 baseline, which might preclude SAF1 from using it at all. I tend to agree with you and I'm not sure keeping it out of SAF1 is a good idea. I was hoping ST would gain a bigger user base by integrating it into SAF1 but I don't think that can happen if we refactor the API. But I believe the API refactoring is a wise choice. So... I'll just play it by ear and see what happens. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]