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: 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, 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
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: [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: [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: 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 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: [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: [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: [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 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: [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: [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] 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
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: 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: 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: 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)
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 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: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: [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: [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: [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: [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 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: 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: [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 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: dependency groupIdorg.apache.struts.tiles/groupId artifactIdtiles-core/artifactId version2.0-r468346-SNAPSHOT/version /dependency 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] 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] 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] 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] 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] Changes in tag libraries
I wonder if it would be possible to provide the combined tiles:insert 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 tiles:insert, so we decided to specialize this tag in different tags, I chose only the names. And I don't think that anyone used tiles:insert 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 tiles:insert tag confusing to me, who finds a proliferation of tiles:insert* 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] 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 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] 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 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: 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: [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 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: [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 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: [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 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] 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] Separate attribute handling from tiles:insert
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, tiles:insert type=attribute/ 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] 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 preparer element (and eventually in a tiles:preparer tag for page-scoped preparers) just like definitions are configured, then a preparer attribute could be added to definition and tiles:definition (and probably tiles:insert 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] 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 definition 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 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: tiletiles:getAsString name=tilte//title or something like that. I would be perfectly fine if I could use tiles:insert in that way if getAsString goes away. So I guess my answer to your question is yes :-) Aarghh! I was wrong, tiles:getAsString name=xxx / is not the same as tiles:insert name=xxx type=string / because it should be an attribute (type=attribute) of type string: yuck two types! At this point I think we should not remove tiles:getAsString 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] Separate attribute handling from tiles:insert
Maybe we need tiles:insertDefintion and tiles:insertAttribute to handle the 2 types specifically instead of one tiles:insert 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 tiles:insert 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 tiles:insert 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 insert tag for generic inserts and insertDefintion, insertAttribute, and insertPage 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 tiles:insert 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 tiles:attribute 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 5, 2006, at 2:46 AM, Antonio Petrelli wrote: Greg Reddin ha scritto: But don't forget about the tiles:getAsString tag as well. It's semantics are quite different from tiles:insert. How would it be affected if we removed the GetTag? I forgot a thing: tiles:getAsString uses GetAttributeTag that does not extend neither GetTag nor InsertTag. Anyway I still think also this tag can be removed, and to use tiles:insert type=string / 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] 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 :-) * get was changed to insert - 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 definition tag and use page to define it everywhere else (put and insert). 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] 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] 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 tiles:getAsString tag as well. It's semantics are quite different from tiles:insert. How would it be affected if we removed the GetTag? I forgot a thing: tiles:getAsString uses GetAttributeTag that does not extend neither GetTag nor InsertTag. Anyway I still think also this tag can be removed, and to use tiles:insert type=string / I'm +1 for that as long as getAsString works the same as insert type=string'. Well not exactly... tiles:getAsString 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 tiles:getAsString? Hmm, I can't find any of my examples of using getAsString but I thought I'd done it like this: tiletiles:getAsString name=tilte/ /title or something like that. I would be perfectly fine if I could use tiles:insert 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] 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 tiles:insert is the most used, even I wrote some tests (in the test webapp) using tiles:insert and I am used to write only tiles:insert But we are cleaning Tiles from the unnecessary and I like tiles:get more (going against my own interests :-) ), simply because it is the opposite of tiles:put, I think it's more intuitive. I'd lean towards keeping tiles:insert 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 tiles:insert says insert this tile or attribute right here on my page whereas tiles:get would say get a tile or attribute from context and let me do something with it later. But don't forget about the tiles:getAsString tag as well. It's semantics are quite different from tiles:insert. 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 definition tag? If so, maybe I intended for the insert tag to not support it. 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:
tiles:put name=something value=titleSomething/title
direct=true/
as opposed to
tiles:put name=something value=/somepage.jsp/
Also you are supposed to be able to use the body of the put tag as
the value:
tiles:put name=something
titlesomething/title
/tiles:put
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=revrev=450403
Log:
SB-21
Removed direct attribute from tiles:put and tiles:add
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=diffrev=450403r1=450402r2=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=diffrev=450403r1=450402r2=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 @@
/description
/attribute
attribute
- namedirect/name
- requiredfalse/required
- rtexprvaluefalse/rtexprvalue
- description
- ![CDATA[
- pDetermines how content is handled: true means content is
- printed emdirect/em/p
- ]]
- /description
- /attribute
- attribute
nametype/name
requiredfalse/required
rtexprvaluefalse/rtexprvalue
@@ -329,19 +318,6 @@
pElement value. Can be a String or Object./p
]]
/description
- /attribute
- attribute
- namedirect/name
- requiredfalse/required
- rtexprvaluefalse/rtexprvalue
- description
- ![CDATA[
- p
- Determines how content is handled: true means content is
- printed emdirect/em
- /p
- ]]
- /description
/attribute
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 tiles:put and tiles:add, 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: 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]
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=revrev=449993 Log: SB-23 Specified rtexprvaluetrue/rtexprvalue 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=diffrev=449993r1=449992r2=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 @@ attribute namename/name requiredtrue/required - rtexprvaluefalse/rtexprvalue + rtexprvaluetrue/rtexprvalue description ![CDATA[ pSpecifies the name under which the newly created definition bean @@ -220,7 +220,7 @@ attribute namename/name requiredfalse/required - rtexprvaluefalse/rtexprvalue + rtexprvaluetrue/rtexprvalue description ![CDATA[ pName of the attribute./p @@ -297,7 +297,7 @@ attribute namename/name requiredtrue/required - rtexprvaluefalse/rtexprvalue + rtexprvaluetrue/rtexprvalue description ![CDATA[ pName of the list./p @@ -323,7 +323,7 @@ attribute namevalue/name requiredfalse/required - rtexprvaluefalse/rtexprvalue + rtexprvaluetrue/rtexprvalue description ![CDATA[ pElement value. Can be a String or Object./p @@ -508,7 +508,7 @@ attribute nameid/name requiredfalse/required - rtexprvaluefalse/rtexprvalue + rtexprvaluetrue/rtexprvalue description ![CDATA[ pDeclared attribute and variable name./p @@ -518,7 +518,7 @@ attribute nameclassname/name requiredfalse/required - rtexprvaluefalse/rtexprvalue + rtexprvaluetrue/rtexprvalue description ![CDATA[ pClass of the declared variable./p @@ -631,7 +631,7 @@ attribute namefile/name requiredtrue/required - rtexprvaluefalse/rtexprvalue + rtexprvaluetrue/rtexprvalue description ![CDATA[ pDefinition file name./p @@ -641,7 +641,7 @@ attribute nameclassname/name requiredfalse/required - rtexprvaluefalse/rtexprvalue + rtexprvaluetrue/rtexprvalue description ![CDATA[ pIf specified, classname of the factory to create and initialized./p - 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 rtexprvaluefalse/rtexprvalue. 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]
[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: 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: [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: [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 tiles:put 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 2:09 AM, Antonio Petrelli wrote: Greg Reddin ha scritto: Of the attributes that are currently supported by InsertTag, I believe the following are redundant: 1) attribute, definition, name could all be resolved to name. ... In addition the name attribute can be interpreted as either a pointer to a Tiles definition or attribute or an URL, which essentially makes it equivalent to page and template. Only a little problem: what if there is a definition that has the same name of an attribute? Will it get the attribute or the definition? I think this is pretty rare, but I think also that it needs attention. Maybe an optional type attribute could be used to distinguish between attribute and name, and when it is absent the tag gives precedence to the attribute. Good call. I'll make sure that gets included. 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 9:32 AM, [EMAIL PROTECTED] wrote: Greg Reddin asked: I'm not really sure what the use of the beanName and beanProperty values are, so if someone wants to enlighten me on that, I'd appreciate it. I would guess that's just to get the tile name from a bean property. With the availability of EL, that seems like an unnecessary feature. That begs the question of the rest of the taglib. Most tags support beanName, beanProperty, and beanScope. Are we at a point where we can assume el yet? Would that preclude Standalone Tiles from being used with Struts 1.x apps? Perhaps the changes I'm proposing will already preclude that. 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]
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]
[Standalone Tiles] Changing the Semantics of the InsertTag
Ticket SB-21 [1] seeks to simplify the Tiles taglib API. First, it's a given that this will break backwards compatibility. You can't reduce an API without breaking compatibility. But as long as we're seeing this version of Tiles as a rework, I don't think it's a problem. Also, I don't think it's a difficult thing to fix in existing applications. No functionality will be removed, but redundant hooks to the same functionality will be removed. Finally, I think this will be one of the greatest improvements to the usability of Tiles. I'm currently working on a patch to implement this. Of the attributes that are currently supported by InsertTag, I believe the following are redundant: 1) attribute, definition, name could all be resolved to name. 2) component, page, and template could all be resolved to template. In addition the name attribute can be interpreted as either a pointer to a Tiles definition or attribute or an URL, which essentially makes it equivalent to page and template. I propose that we reduce all these meanings down to the name attribute. IOW, name can be a definition name or an attribute name. I suspect this is how Tiles is being used in 90% of applications anyway. I know that's how I use it. Further, I propose that we reduce all the URL-based attributes to the template attribute. So if you want to directly insert a page you must use the template attribute. The net result is that you can use the insert tag in the following ways: tiles:insert name=someName/ - to insert a Tiles definition or attribute. tiles:insert template=/somepage.jsp/ - to insert a URL. I'm not really sure what the use of the beanName and beanProperty values are, so if someone wants to enlighten me on that, I'd appreciate it. Finally, I personally don't see the use for including a controllerClass or controllerUrl in the insert tag. IMO, if you want to do something like that you should use the definition tag instead. I still intend to completely support attributes defined in the tag body as such: tiles:insert name=someDefinition tiles:put name=someAttribute value=someValue/ /tiles:insert And the other attributes like flush, ignore, and role will continue to function as always. Have I left out any major uses of the insert tag? Does this change remove any functionality that anyone is currently relying on? Thanks, Greg [1] http://issues.apache.org/struts/browse/SB-21 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tiles] Inline definitions (WAS: [Tiles] Embedding tiles inside of tiles)
On Jun 9, 2006, at 3:10 AM, Antonio Petrelli wrote: put name=attributeName value=some.definition type=definition / I don't think it is what you mean, because this is already there. Can you clarify what you mean with an example? No that's what I meant. I just never have actually used that. How does that look on the JSP doing tiles:insert/? You'd think I'd know this already :-) If that works the way I think it does then I'd much prefer that than the nested tiles. I'm not against support for the nested tiles, I'd probably just never use it myself. I think it makes things look cleaner if you do something like the above. Of course I rarely use nested anonymous classes with Java either. But it's just a personal preference. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tiles] Inline definitions (WAS: [Tiles] Embedding tiles inside of tiles)
Yep, that's come up before. Personally, I don't like the idea. Think about how complicated that could become with nested, nested defs. I'd prefer better support for including other definitions as a tile attribute. Maybe that support is there already and i just haven't tried it. Greg On Jun 8, 2006, at 11:06 AM, Antonio Petrelli wrote: Greg Reddin ha scritto: As long as your layout is completely defined in one JSP page this will all work. It breaks down if your layout has separate pages for header, footer, etc. See below: definition name=tileA path=/layout.jsp put name=header value=/header1.jsp/ put name=headerGraphic value=image1.gif/ put name=someOtherThing value=.../ /definitioin definition name=tileB extends=tileA put name=header value=header2.jsp/ put name=headerGraphic value=image2.gif/ /definition Above you want to define your header differently for two layouts and you want to pass different images in. This won't work because the headerGraphic attribute will not be passed along to the header page unless you do it manually from the page where it is inserted. Uh, this makes me think about a possibility to support something like inline definitions such as: definition name=tileB extends=tileA put name=header definition path=/header2.jsp put name=headerGraphic value=image2.gif / /definition /put put name=headerGraphic value=image2.gif/ /definition Do you think it could be a good solution? 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: [Standalone Tiles] DefinitionsFactory and TilesContext
I don't know if I'll have time to look at the patch today, but I'll get to it ASAP. See one comment below: On Jun 6, 2006, at 7:28 AM, Antonio Petrelli wrote: But I think that most of the time addDefinitions() will be called at servlet init time and many of the components in TilesContext will not be available. But there are already cases where that situation exists. If there is no TilesContext, probably there would not be a Locale either (but I could miss something) and the non-locale definitions are read by DefinitionsFactory.readDefinitions(). I don't get the point... That's probably true (no context == no locale), but in the servlet init phase we are processing definitions files that have locale information encoded into the filename (i.e. tiles-defs_en_US.xml). There we have a locale and a partial TilesContext, one with Servlet/ Portlet context info but not request info. I can think of a couple of places where TilesContext is used like this right now. Maybe it calls for a context interface that is used in the init phase and another more complete context interface that is used in the request phase but, personally, that would be more complicated than I want. You just have to be aware of your context when using TilesContext. Does that clear it up? Again, I'll look at your patch. I think I'm in favor of what you are proposing. But the devil's in the details, right? :-) Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Standalone Tiles] DefinitionsFactory and TilesContext
On Jun 5, 2006, at 6:43 AM, Antonio Petrelli wrote: Hello there... (I just don't know a better way to start a letter, gosh...) I have the same problem sometimes :-) Anyway, the big problem is that I need to use TilesContext for examining the HTTP header and beans in session scope. The last class that is aware of TilesContext is TilesUtilImpl, that is not very configurable. So I modified the signature of some methods of DefitionsFactory (and its main implementation UrlDefinitionsFactory) replacing the Locale with a TilesContext and added a getDefinition method. I don't have a problem *adding* TilesContext to the DefinitionsFactory interface. Are you talking about readDefinitions (), addDefinitions(), etc. Could you post the changes you made to DefinitionsFactory and UrlDefinitionsFactory? I think that would give me a better idea of the impact. Then I moved some code from TilesUtilImpl to UrlDefinitionsFactory so that all the creation of new ComponentDefinitions instances are made directly from UrlDefinitionsFactory and, surprise!, some of the methods declared public do not need to be public anymore (like isLocaleProcessed). I like this change. The only thing I find bothersome about it is that it's similar to how XmlDefinitions was introduced in Struts- Tiles. What I mean is this: XmlDefinitionsFactory (or whatever the class name is extended DefinitionsFactory, but added features that were really part of core Tiles functionality rather than simply part of an XML-based implementation. It seems we are doing the same thing here by putting some core functionality in a default implementation of the DefinitionsFactory. But maybe the UrlDefinitionsFactory is generic enough that it wouldn't matter. The big issue (if it can be called this way) is that, in my local version, DefinitionsFactory must read TilesContext and not Locale. So my question is: do you think that DefinitionsFactory should use TilesContext, then leaving to the specific implementation the way this context is processed, or should it use Locale directly, though ComponentDefinitions already uses it for its own storing mechanism? I'm undecided on this. I lean towards still requiring a locale directly since that object acts as a key into the definitions map. But, I get the feeling that in most places locale is on the interface, it will be in the context of a request. In that case I can see the value of having the full context around - especially since it's no longer married to the servlet API. But I think that most of the time addDefinitions() will be called at servlet init time and many of the components in TilesContext will not be available. But there are already cases where that situation exists. There could be another way to solve the issue: put something configurable between TilesUtilImpl and DefinitionsFactory that processes the TilesContext instance, but it will be another level of indirection (read: slowness). That seems like too many layers to me. Go ahead and publish your code. I think it would be easier to evaluate the concepts if I could actually look at it. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Reorg (Was -- Re: [shale] Maven 2 build -- Help Wanted)
On Jun 2, 2006, at 2:20 AM, James Mitchell wrote:
The group id for Standalone Tiles (sandbox/tiles) says
'org.apache.struts.tiles'. Are we waiting till Tiles moves out of
sandbox before we change that to 'org.apache.tiles'? I'd like to
change it now. Your thoughts?
Wendy, correct me if I'm wrong, but I think this is done because the
base group id for Struts is org.apache.struts and as long as Tiles is
still part of Struts it will need to retain the struts part of the
group id.
/**
* This view handler strips the suffix off of the view ID and looks
@@ -263,7 +265,7 @@
ServletRequest servletRequest = (ServletRequest) request;
ServletContext servletContext = (ServletContext) context;
try {
- tile = TilesUtil.getDefinition(name, servletRequest,
servletContext);
+ tile = TilesUtil.getDefinition(name, new
ServletTilesContext(servletContext, (HttpServletRequest)
servletRequest));
This is part of my lack of knowledge of JSF. But is the view handler
already married to the servlet API or is it possible to get here and
be in the portlet API? You should probably be using the
TilesContextFactory here to be more generic.
Index: tiles-core/src/main/java/org/apache/tiles/ComponentContext.java
===
--- tiles-core/src/main/java/org/apache/tiles/
ComponentContext.java (revision 411013)
+++ tiles-core/src/main/java/org/apache/tiles/
ComponentContext.java (working copy)
@@ -25,6 +25,7 @@
import java.util.Map;
import java.util.Set;
+import javax.servlet.ServletRequest;
import javax.servlet.jsp.PageContext;
import org.apache.tiles.taglib.ComponentConstants;
@@ -186,6 +187,14 @@
}return (ComponentContext)
tilesContext.getRequestScope().get(
ComponentConstants.COMPONENT_CONTEXT);
}
+
+static public ComponentContext getContext(ServletRequest
request) {
+ if (request.getAttribute(javax.servlet.jsp.jspException) !
= null) {
+ return null;
+ }
We can't put Servlet API dependencies on the Tiles API. One of the
core objectives for Standalone Tiles is to factor out dependencies on
the Servlet API. The above method should be using TilesContext.
+static public void setContext(
+ ComponentContext context, ServletRequest request) {
+
+ request.setAttribute(ComponentConstants.COMPONENT_CONTEXT,
context);
+}
Again, use TilesContext here instead of ServletRequest.
Thanks for doing this. My *real* job is killing me this week :-)
Greg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
