Re: [VOTE] How should Tiles be refactored?How
Cedric, I wasn't trying to step on toes :-) I can't say how much more I'd prefer you refactor Tiles than me. You (obviously) are a *lot* more familiar with it's inner workings! The point to keep in mind though is that 1.1 *is* about seperatism. Would it, in your opinion, require undoing changes made in 1.1 to enforce seperatism to acheive a better affect in 1.2? I like your intent, I believe, very much. 1.2 is really the target for making modules work together though - that should be it's primary focus. If you're working on resolving this I'll just bow out and let you have it :-) Please let me know. I'm still reviewing the code to make absolutely sure I know what I'm doing before I go to changing anything, and I'd hate to be throwing wasted time into the effort - especially when a much more competent person is at hand. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How should Tiles be refactored?How
10/17/2002 7:23:27 AM, Cedric Dumoulin [EMAIL PROTECTED] wrote: Of course, we can conciliate both, but this require some thinking: * A tiles configuration file requires some references to common URLs and to common definitions. o How to distinguish between an URL from the module namespace and an URL from another namespace (common, root or other module), without overloading too much the configuration file ? o The same for definitions * We can think of a module containing all commons files (tiles, layouts, definitions). How to reference these entities from other modules ? * Each modules will certainly share a set of common tiles configurations. How to do that without replications ? So what we need now is to specify what could be the Tiles syntax and how it will be used in the context of modules. After that it will be possible to make tiles modules compliant. I believe all we really need to do is to add a contextRelative property to the put and insert elements/tags and the corresponding object. This way we could specify contextRelative=true for the tiles that are being shared between modules. -Ted. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How should Tiles be refactored?How
Hi Eddie, Eddie Bush wrote: Cedric, I wasn't trying to step on toes :-) I can't say how much more I'd prefer you refactor Tiles than me. You (obviously) are a *lot* more familiar with it's inner workings! The point to keep in mind though is that 1.1 *is* about seperatism. If you have a strong separation between modules with Tiles, you go against the Tiles philosophy (share to reuse, to reduce maintenance, ...). If you do strong separation, you will be consistent with the module philosophy, but you will be inconsistent with the Tiles one. So, peoples using Tiles will not use modules because they will loose one of its main advantage. So, we need a way to conciliate both philosophy. My idea was to have one Tiles factory per module, and to have a syntax allowing cross references between module namespaces (for URL). Also, a same tiles config file could be used by several factories, allowing some commons basic definitions. This later requirement bring some problems: the shared config file namespace is not the same depending on the loading module. In this case, how to specify URLs in a way consistent to module philosophy ? Should we mark all as contextRelative=false ? If yes, what will happen if the module name change ? This is such little things that need to be solved in order to propose a consistent behavior. After that, it will be more easy to implement something ! Would it, in your opinion, require undoing changes made in 1.1 to enforce seperatism to achieve a better affect in 1.2? I like your intent, I believe, very much. 1.2 is really the target for making modules work together though - that should be it's primary focus. The Tiles goal of sharing common pages should be maintained in 1.1. The module goal is to let separate teams work independently on different modules. In this context, Tiles should combine both goals. If you're working on resolving this I'll just bow out and let you have it :-) Please let me know. I'm still reviewing the code to make absolutely sure I know what I'm doing before I go to changing anything, and I'd hate to be throwing wasted time into the effort - especially when a much more competent person is at hand. Your help is welcome. Also, someone else than me with a very well understanding of the Tiles philosophy and its current implementation is more than welcome. But, please, don't forget to expose your intention to other commiters before making heavy changes. The best is to describe your goals, your expected behavior, and maybe a simple example of use. Only after that you can propose an implementation. Cedric -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How should Tiles be refactored?How
10/18/2002 5:42:20 AM, Cedric Dumoulin [EMAIL PROTECTED] wrote: If you have a strong separation between modules with Tiles, you go against the Tiles philosophy (share to reuse, to reduce maintenance, ...). If you do strong separation, you will be consistent with the module philosophy, but you will be inconsistent with the Tiles one. So, peoples using Tiles will not use modules because they will loose one of its main advantage. So, we need a way to conciliate both philosophy. My idea was to have one Tiles factory per module, and to have a syntax allowing cross references between module namespaces (for URL). Also, a same tiles config file could be used by several factories, allowing some commons basic definitions. This later requirement bring some problems: the shared config file namespace is not the same depending on the loading module. In this case, how to specify URLs in a way consistent to module philosophy ? Should we mark all as contextRelative=false ? If yes, what will happen if the module name change ? This is such little things that need to be solved in order to propose a consistent behavior. After that, it will be more easy to implement something ! I think the important thing is to be able to share the physical tiles, include the layouts, by being able to specify contextRelative=true when appropriate. This would let them keep all the shared files in a common folder (or equivalent) off the application root. In practice, I think most of the Definitions will fall along module lines, but we will still want to use a handful of base definitions that each module will extend. Since Tiles accepts a list of comma-delimited configurations, one of these could be the global definitions that the modules all extend. There will be some redundency in that each module will create its own runtime copy of the base definitions, but that sounds like small change to me. I agree with Martin in that it would be best if all the configuration files followed the same patterns. In a later release, perhaps we can get the other files extending elemenets too, at which time we can come up with a cleaner implementation for a shared configuration. But for now, if + each module could use its own attribute to store it Definitions, and + we can still specify a list of configuations for each module, and + we can specify contextRelative=True where appropriate (on an element-by-element +basis) I think we would be good =:0 -Ted. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How should Tiles be refactored?How
Ted Husted wrote: snip/ But for now, if + each module could use its own attribute to store it Definitions, and + we can still specify a list of configuations for each module, and + we can specify contextRelative=True where appropriate (on an element-by-element basis) I think we would be good =:0 I think that's probably the best solution we have for 1.1. -Ted. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How should Tiles be refactored?How
Hi again, Cedric :-) Cedric Dumoulin wrote: Hi Eddie, Eddie Bush wrote: Cedric, I wasn't trying to step on toes :-) I can't say how much more I'd prefer you refactor Tiles than me. You (obviously) are a *lot* more familiar with it's inner workings! The point to keep in mind though is that 1.1 *is* about seperatism. If you have a strong separation between modules with Tiles, you go against the Tiles philosophy (share to reuse, to reduce maintenance, ...). If you do strong separation, you will be consistent with the module philosophy, but you will be inconsistent with the Tiles one. So, peoples using Tiles will not use modules because they will loose one of its main advantage. So, we need a way to conciliate both philosophy. My idea was to have one Tiles factory per module, and to have a syntax allowing cross references between module namespaces (for URL). Also, a same tiles config file could be used by several factories, allowing some commons basic definitions. This later requirement bring some problems: the shared config file namespace is not the same depending on the loading module. In this case, how to specify URLs in a way consistent to module philosophy ? Should we mark all as contextRelative=false ? If yes, what will happen if the module name change ? This is such little things that need to be solved in order to propose a consistent behavior. After that, it will be more easy to implement something ! You and I are in the same camp on this, but I don't think now is the time for significant change. We need to hurry 1.1, and the only way I see to do that is for each of us to agree to seperatism in 1.1 - understanding and *expecting* that 1.2 will be our chance to solve the problems we wanted to solve in 1.1 but couldn't (because of time). Would it, in your opinion, require undoing changes made in 1.1 to enforce seperatism to achieve a better affect in 1.2? I like your intent, I believe, very much. 1.2 is really the target for making modules work together though - that should be it's primary focus. The Tiles goal of sharing common pages should be maintained in 1.1. The module goal is to let separate teams work independently on different modules. In this context, Tiles should combine both goals. See Ted's note about specifying global definitions. I think that may suffice. I *know* :-) it's not something you (or I) will find ideal, but can we please overlook that for 1.1 and focus on utopia in 1.2? There's a lot of folks that would love to use 1.1 right now, and can't simply because it has a beta in it's name. Those people who *are* using modules would not be affected by us at all from what I can tell - they simply cannot use tiles at this point :-( not in non-default modules! (I resorted to using definitions defined in JSP - that *does* work. It's a compromise I'd like to get away from as quickly as possible though). So, can we *please* aim for seperatism in 1.1 and then focus purely on how sharing should be done in 1.2? If you're working on resolving this I'll just bow out and let you have it :-) Please let me know. I'm still reviewing the code to make absolutely sure I know what I'm doing before I go to changing anything, and I'd hate to be throwing wasted time into the effort - especially when a much more competent person is at hand. Your help is welcome. Also, someone else than me with a very well understanding of the Tiles philosophy and its current implementation is more than welcome. But, please, don't forget to expose your intention to other commiters before making heavy changes. The best is to describe your goals, your expected behavior, and maybe a simple example of use. Only after that you can propose an implementation. Thanks for the guidebook :-) I don't think I've heard anything stated so clearly about how to proceed - that certainly does make a lot of sense to me though. Cedric -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How should Tiles be refactored?How
Eddie Bush wrote: Hi again, Cedric :-) We need to hurry 1.1, and the only way I see to do that is for each of us to agree to seperatism in 1.1 - understanding and *expecting* that 1.2 will be our chance to solve the problems we wanted to solve in 1.1 but couldn't (because of time). I am sorry, but I still disagree on the separatism point ;-). Or maybe we don't understand the same thing by separatism. Tiles is a framework to share common piece of work. You can't say now: Tiles allow to share work, but you still have to duplicate when you use module ! The Ted's proposal is a good starting point. We need now to check if it fulfill simple needs, and if there is no incompatibility with complex cases. I will check that with existing applications. Implementing it doesn't seem too complicated. Cedric -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How should Tiles be refactored?How
10/18/2002 9:45:49 AM, Cedric Dumoulin [EMAIL PROTECTED] wrote: The Ted's proposal is a good starting point. We need now to check if it fulfill simple needs, and if there is no incompatibility with complex cases. I will check that with existing applications. Implementing it doesn't seem too complicated. +1 I have a complex use case in front of my that I could convert to modules and test the implementation. There are eight modules. Each has it's own set of fillin pages, but they all share the same base tiles. I'll put these in a root definition file, and then list that for each module, along with the module's specific Definitions. I'm confident that the only redundency will be in the base Defintion objects being created more than once on the server, but that will be transparent to the devleloper. -Ted. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How should Tiles be refactored?How
10/18/2002 9:19:26 AM, Eddie Bush [EMAIL PROTECTED] wrote: You and I are in the same camp on this, but I don't think now is the time for significant change. We need to hurry 1.1, and the only way I see to do that is for each of us to agree to seperatism in 1.1 - understanding and *expecting* that 1.2 will be our chance to solve the problems we wanted to solve in 1.1 but couldn't (because of time). Could we please speak in terms of Sruts 1.2.x ? If we implement some other useful things, and this new module implementation isn't ready, I don't want statements like this to come backs as a veto on a 1.2.0 release. Please, no more gotta have its targeted for a specific release. If a feature is ready, it's ready, if not, it can wait for the next iteration. (We just need more iterations :0) We do need to be agile in terms of the remaining tasks for 1.1.0. But I'm concerned that there be any implication that we are ready to sacrifice quality for expediency. We all agree that there are other approaches to modules, but we need to finish this one before we consider the others. I don't believe that's hurrying, it's simply coding and releasing one use-case at a time. -Ted. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How should Tiles be refactored?How
Ted Husted wrote: 10/18/2002 9:19:26 AM, Eddie Bush [EMAIL PROTECTED] wrote: You and I are in the same camp on this, but I don't think now is the time for significant change. We need to hurry 1.1, and the only way I see to do that is for each of us to agree to seperatism in 1.1 - understanding and *expecting* that 1.2 will be our chance to solve the problems we wanted to solve in 1.1 but couldn't (because of time). Could we please speak in terms of Sruts 1.2.x ? Sorry - yes. That's actually what I meant, but I do see where it's not clear. If we implement some other useful things, and this new module implementation isn't ready, I don't want statements like this to come backs as a veto on a 1.2.0 release. Please, no more gotta have its targeted for a specific release. If a feature is ready, it's ready, if not, it can wait for the next iteration. (We just need more iterations :0) We do need to be agile in terms of the remaining tasks for 1.1.0. But I'm concerned that there be any implication that we are ready to sacrifice quality for expediency. Agreed. What is in 1.1.0 should be solid. That's not to say it will be as feature-full as we would like (wrt sharing). We all agree that there are other approaches to modules, but we need to finish this one before we consider the others. I don't believe that's hurrying, it's simply coding and releasing one use-case at a time. Right. -Ted. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: [VOTE] How should Tiles be refactored?How
Eddie, I am a long time Struts/Tiles users, and I response to this group once in a while or when needed too. Just because I seemly bussy with my daily work. I have high respect for the 'OG' Struts contributors, lik Craig, Ted, Cedric, and many others group users, whose believe in making a different in raising web application development to a higher standard. Every since I see your name appear on the list, I Starting to wonder??? Eddie, beside 'entertaining' people do you have any other thing to do? May be, A real Job?. --danny Ps. If I've offended anyone, I am sorry -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Friday, October 18, 2002 7:02 AM To: Struts Developers List Subject: Re: [VOTE] How should Tiles be refactored?How Cedric Dumoulin wrote: Eddie Bush wrote: Hi again, Cedric :-) We need to hurry 1.1, and the only way I see to do that is for each of us to agree to seperatism in 1.1 - understanding and *expecting* that 1.2 will be our chance to solve the problems we wanted to solve in 1.1 but couldn't (because of time). I am sorry, but I still disagree on the separatism point ;-). Or maybe we don't understand the same thing by separatism. Tiles is a framework to share common piece of work. You can't say now: Tiles allow to share work, but you still have to duplicate when you use module ! I'm going to shut up now :-) I was just looking at ways to expedite 1.1F. The Ted's proposal is a good starting point. We need now to check if it fulfill simple needs, and if there is no incompatibility with complex cases. I will check that with existing applications. Implementing it doesn't seem too complicated. Even having seperatism in 1.1 would be better than the current support non-default modules have -- wouldn't you agree? It's one step in the right direction. I *do* realize what I suggest is less than desirable -- and I personally wouldn't complain if you commited code that gave us something better -- but we should be focused primarily on 1.1F having modules that work - even if not as fully as we'd like (ie. there is not sharing). Cedric As I said, I'm going to shut up and find something else to fix. It sounds like you have this well in-hand, and discussing it to death is just going to prolong the process of effecting whatever change comes. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How should Tiles be refactored?How
I do not have as my goal to entertain. While you may disagree, I think I add value. Yes, I may pull a stick out and stir things up, but, if/when I do, it is done so that something meaningful can come of it. Rather than proceed off in a direction people disagree with, and that is bad for Struts, I prefer to find out what consensus is on a topic and proceed from there. If you don't like what I have to say, filter my posts :-) Trieu, Danny wrote: Eddie, I am a long time Struts/Tiles users, and I response to this group once in a while or when needed too. Just because I seemly bussy with my daily work. I have high respect for the 'OG' Struts contributors, lik Craig, Ted, Cedric, and many others group users, whose believe in making a different in raising web application development to a higher standard. Every since I see your name appear on the list, I Starting to wonder??? Eddie, beside 'entertaining' people do you have any other thing to do? May be, A real Job?. --danny Ps. If I've offended anyone, I am sorry -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: [VOTE] How should Tiles be refactored?How
No, what you did was the equivalent of punching someone in the face whilst saying sorry. If you were really sorry, you wouldnt have posted it in the first place. In fact, your entire post may have been more effective had you asked Eddie what he plans to do to contribute to the Struts effort - rather than poke him with facetious comments. I concur that I have had my reservations about Eddie. That's not to say I disagree with his committer status, but I reserve my final judgement until we see what Eddie can really do. One thing is apparent thus far - he is willing to get involved, and get his hands dirty, and unlike the majority of committers - he is also very willing to listen to what us mortals have to say. That's not to say that the other committers arent listening, dont get me wrong - but Eddie is interactive. And there is bound to be a period of uncertainty as Eddie finds his feet. If he's wrong for the job, I'm sure the other committers will deal with it as they see fit. But in order for Eddie to have been elevated to committer status, the other committers must have seen some value in him. Give him a chance. -Original Message- From: Trieu, Danny [mailto:DTrieu;downeysavings.com] Sent: 18 October 2002 17:24 To: 'Struts Developers List' Subject: RE: [VOTE] How should Tiles be refactored?How Yes, I am guilty of the crime I committed and I already said 'I am sorry'. Do you want me to Said it again for you? --danny -Original Message- From: Chanoch [mailto:mail;chanoch.com] Sent: Friday, October 18, 2002 9:04 AM To: 'Struts Developers List' Subject: RE: [VOTE] How should Tiles be refactored?How If this list turns into another Tomcat dev abuse list I think it will be put many people off - I don't think these types of comments are contructive in any way - i.e. they don't contribute to the effort or the list and you are therefore guilty of the crime you accuse Eddie of. If you have a different way of saying what you want from him then perhaps that would be helpful. chanoch - The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Although we routinely screen for viruses, recipients should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments. -Original Message- From: Trieu, Danny [mailto:DTrieu;downeysavings.com] Sent: 18 October 2002 16:32 To: 'Struts Developers List' Subject: RE: [VOTE] How should Tiles be refactored?How Eddie, I am a long time Struts/Tiles users, and I response to this group once in a while or when needed too. Just because I seemly bussy with my daily work. I have high respect for the 'OG' Struts contributors, lik Craig, Ted, Cedric, and many others group users, whose believe in making a different in raising web application development to a higher standard. Every since I see your name appear on the list, I Starting to wonder??? Eddie, beside 'entertaining' people do you have any other thing to do? May be, A real Job?. --danny Ps. If I've offended anyone, I am sorry -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Friday, October 18, 2002 7:02 AM To: Struts Developers List Subject: Re: [VOTE] How should Tiles be refactored?How Cedric Dumoulin wrote: Eddie Bush wrote: Hi again, Cedric :-) We need to hurry 1.1, and the only way I see to do that is for each of us to agree to seperatism in 1.1 - understanding and *expecting* that 1.2 will be our chance to solve the problems we wanted to solve in 1.1 but couldn't (because of time). I am sorry, but I still disagree on the separatism point ;-). Or maybe we don't understand the same thing by separatism. Tiles is a framework to share common piece of work. You can't say now: Tiles allow to share work, but you still have to duplicate when you use module ! I'm going to shut up now :-) I was just looking at ways to expedite 1.1F. The Ted's proposal is a good starting point. We need now to check if it fulfill simple needs, and if there is no incompatibility with complex cases. I will check that with existing applications. Implementing it doesn't seem too complicated. Even having seperatism in 1.1 would be better than the current support non-default modules have -- wouldn't you agree? It's one step in the right direction. I *do* realize what I suggest is less than
RE: [VOTE] How should Tiles be refactored?How
Danny, Your comments are welcome on the list as long as they are respectful. Adding a PS. sorry if I offend anyone does not cut it here. In the future, please be more considerate to others. Thanks, David From: Trieu, Danny [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: [VOTE] How should Tiles be refactored?How Date: Fri, 18 Oct 2002 09:23:51 -0700 Yes, I am guilty of the crime I committed and I already said 'I am sorry'. Do you want me to Said it again for you? --danny -Original Message- From: Chanoch [mailto:mail;chanoch.com] Sent: Friday, October 18, 2002 9:04 AM To: 'Struts Developers List' Subject: RE: [VOTE] How should Tiles be refactored?How If this list turns into another Tomcat dev abuse list I think it will be put many people off - I don't think these types of comments are contructive in any way - i.e. they don't contribute to the effort or the list and you are therefore guilty of the crime you accuse Eddie of. If you have a different way of saying what you want from him then perhaps that would be helpful. chanoch - The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Although we routinely screen for viruses, recipients should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments. -Original Message- From: Trieu, Danny [mailto:DTrieu;downeysavings.com] Sent: 18 October 2002 16:32 To: 'Struts Developers List' Subject: RE: [VOTE] How should Tiles be refactored?How Eddie, I am a long time Struts/Tiles users, and I response to this group once in a while or when needed too. Just because I seemly bussy with my daily work. I have high respect for the 'OG' Struts contributors, lik Craig, Ted, Cedric, and many others group users, whose believe in making a different in raising web application development to a higher standard. Every since I see your name appear on the list, I Starting to wonder??? Eddie, beside 'entertaining' people do you have any other thing to do? May be, A real Job?. --danny Ps. If I've offended anyone, I am sorry -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Friday, October 18, 2002 7:02 AM To: Struts Developers List Subject: Re: [VOTE] How should Tiles be refactored?How Cedric Dumoulin wrote: Eddie Bush wrote: Hi again, Cedric :-) We need to hurry 1.1, and the only way I see to do that is for each of us to agree to seperatism in 1.1 - understanding and *expecting* that 1.2 will be our chance to solve the problems we wanted to solve in 1.1 but couldn't (because of time). I am sorry, but I still disagree on the separatism point ;-). Or maybe we don't understand the same thing by separatism. Tiles is a framework to share common piece of work. You can't say now: Tiles allow to share work, but you still have to duplicate when you use module ! I'm going to shut up now :-) I was just looking at ways to expedite 1.1F. The Ted's proposal is a good starting point. We need now to check if it fulfill simple needs, and if there is no incompatibility with complex cases. I will check that with existing applications. Implementing it doesn't seem too complicated. Even having seperatism in 1.1 would be better than the current support non-default modules have -- wouldn't you agree? It's one step in the right direction. I *do* realize what I suggest is less than desirable -- and I personally wouldn't complain if you commited code that gave us something better -- but we should be focused primarily on 1.1F having modules that work - even if not as fully as we'd like (ie. there is not sharing). Cedric As I said, I'm going to shut up and find something else to fix. It sounds like you have this well in-hand, and discussing it to death is just going to prolong the process of effecting whatever change comes. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail
Re: [VOTE] How should Tiles be refactored?How
On Fri, 18 Oct 2002, Ted Husted wrote: But for now, if + each module could use its own attribute to store it Definitions, and + we can still specify a list of configuations for each module, and + we can specify contextRelative=True where appropriate (on an element-by-element basis) I think we would be good =:0 +1 on this for Struts 1.1. I'm (slowly but surely) getting sold on some form of cross-module sharing in 1.2. If we go that way, it would be much more appropriate for *all* components of Struts to be consistent with how they do this, in both 1.1 and 1.2. Cedric, your concerns about reusability really do resonate. Indeed, this is one of the things that makes Tiles so popular. This proposal keeps that feature for intra-module use (and, indeed, extends it so that Tiles is useful in non-default modules), and lays the groundwork for solving cross-module sharing/inheritance/whatever (for all Struts features) in a coordinated way in the future. OK? -Ted. Craig -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How should Tiles be refactored?How
Ok, thanks guys - can we drop it and move on now? :-) David Graham wrote: Danny, Your comments are welcome on the list as long as they are respectful. Adding a PS. sorry if I offend anyone does not cut it here. In the future, please be more considerate to others. Thanks, David -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How should Tiles be refactored?How
Cedric Dumoulin wrote: In fact, I have already think about how to make Tiles more modules/sub-apps compliant. I haven't solved this question, because there is some opposite views: modules are intended to clearly separate works (the Ted's chinese wall), and Tiles are intended to avoid duplications by allowing sharing of common jsp. Of course, we can conciliate both, but this require some thinking: * A tiles configuration file requires some references to common URLs and to common definitions. o How to distinguish between an URL from the module namespace and an URL from another namespace (common, root or other module), without overloading too much the configuration file ? Must admit I favour one level of Modules, because it makes sense. You may want to have many modules (different applications) to share the same web application context. I also favour in that case separate namespaces but there should be a get out clause or API hook which allows developer to get to the default Module if required. This would help us with Expresso, which would be for us always the default Module. I cannot see the reason for Modules of Modules of Modules ad infinitum. Why? -- Peter Pilgrim ServerSide Java Specialist My on-line resume and for interview videos about myself, J2EE Open Source, Struts and Expresso. || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How should Tiles be refactored?How
Cliff Rowley wrote: My on-line resume and for interview videos about myself, J2EE Open Source, Struts and Expresso. || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' Sorry, a tiny OT - I just checked out your website Peter, LOL at your how-to videos - you big poser! ;) I set up the camera at the computer desk in one of the bedrooms in my house. Afterall it is meant to impress potential recruiters. 'pose I could replace the books with a flowers and vase, then you might call me queer (no I am straight heterosexual mate) LOL -- Peter Pilgrim ServerSide Java Specialist My on-line resume and for interview videos about myself, J2EE Open Source, Struts and Expresso. || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How should Tiles be refactored?How
Eddie Bush wrote: Cast your vote. [ -1] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [ -1 ] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. Here are some key benefits of Tiles: * Allows consistent look and feel across all your pages * Allows modification of this look and feel in one single central point * Avoids duplication of common files (common layout, headers, footers, menu, ...) If there one independent configuration for each module, you loose all these functionalities. This would be a regression. [ 0] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by a switch which defaults to off [ 1] I want tiles to have a different configuration (Elaborate). In fact, I have already think about how to make Tiles more modules/sub-apps compliant. I haven't solved this question, because there is some opposite views: modules are intended to clearly separate works (the Ted's chinese wall), and Tiles are intended to avoid duplications by allowing sharing of common jsp. Of course, we can conciliate both, but this require some thinking: * A tiles configuration file requires some references to common URLs and to common definitions. o How to distinguish between an URL from the module namespace and an URL from another namespace (common, root or other module), without overloading too much the configuration file ? o The same for definitions * We can think of a module containing all commons files (tiles, layouts, definitions). How to reference these entities from other modules ? * Each modules will certainly share a set of common tiles configurations. How to do that without replications ? So what we need now is to specify what could be the Tiles syntax and how it will be used in the context of modules. After that it will be possible to make tiles modules compliant. Cedric -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] How should Tiles be refactored?
[ ] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [X] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. [ ] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by a switch which defaults to off [ ] I want tiles to have a different configuration (Elaborate). -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] How should Tiles be refactored?
All the configuration files for Struts core, Validator, and Tiles should work the same way. Tiles put and insert should support a contextRelative property, like the ActionForward. 10/16/2002 3:48:56 PM, Eddie Bush [EMAIL PROTECTED] wrote: There's been a lot of discussion on how 1.1 final should look, and I think it's good to have such discussions. We (commiters and non), being tasked with implementing everything that is Struts 1.1, need to have a clear picture of exactly what that means. Now, when it gets right now to brass tacks, it's irrelevant to me which way we go on this (right now - I think my position is well-known). Something has to be done though. Progress needs to be made, and to make progress we must have a clear understanding of how we should proceed. Tiles will not work as expected with modules and that needs to be fixed. What form should it take? I'm tired of speculation. I'm happy to study Tiles and determine what needs to change, but I will not take the decision of how to implement it upon myself. Please bear in mind that we have folks waiting on 1.1F very anxiously and that any behavior can be rectified in a later release. Also note that refactoring to support a dependent configuration would not undo (that I can see) any change which would be required to make the configurations entirely independent. That is a necessary step. The only question is if/when the next step of allowing sharing across modules should occur. Cast your vote. [ ] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [ ] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. [ ] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by a switch which defaults to off [ ] I want tiles to have a different configuration (Elaborate). -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] How should Tiles be refactored?
Independent configuration files for 1.1, possible sharing in 1.2. So, I guess that's number 2. Dave From: Eddie Bush [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: [VOTE] How should Tiles be refactored? Date: Wed, 16 Oct 2002 14:48:56 -0500 There's been a lot of discussion on how 1.1 final should look, and I think it's good to have such discussions. We (commiters and non), being tasked with implementing everything that is Struts 1.1, need to have a clear picture of exactly what that means. Now, when it gets right now to brass tacks, it's irrelevant to me which way we go on this (right now - I think my position is well-known). Something has to be done though. Progress needs to be made, and to make progress we must have a clear understanding of how we should proceed. Tiles will not work as expected with modules and that needs to be fixed. What form should it take? I'm tired of speculation. I'm happy to study Tiles and determine what needs to change, but I will not take the decision of how to implement it upon myself. Please bear in mind that we have folks waiting on 1.1F very anxiously and that any behavior can be rectified in a later release. Also note that refactoring to support a dependent configuration would not undo (that I can see) any change which would be required to make the configurations entirely independent. That is a necessary step. The only question is if/when the next step of allowing sharing across modules should occur. Cast your vote. [ ] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [ ] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. [ ] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by a switch which defaults to off [ ] I want tiles to have a different configuration (Elaborate). -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] How should Tiles be refactored?
See if I draw little boxes for you guys anymore! Bah - none of you use them ;-) David Graham wrote: Independent configuration files for 1.1, possible sharing in 1.2. So, I guess that's number 2. Dave -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] How should Tiles be refactored?
Well, I know I'm not a committer and all hanging-head, but for what its worth... [ ] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [ ] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. [ x ] I DON'T think we should allow naked pictures of the committers on the main pageDOH HAHAHAHA [ ] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by a switch which defaults to off [ ] I want tiles to have a different configuration (Elaborate). James ...and you thought I was serious for a sec huh? Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:49 PM To: Struts Developers List Subject: [VOTE] How should Tiles be refactored? There's been a lot of discussion on how 1.1 final should look, and I think it's good to have such discussions. We (commiters and non), being tasked with implementing everything that is Struts 1.1, need to have a clear picture of exactly what that means. Now, when it gets right now to brass tacks, it's irrelevant to me which way we go on this (right now - I think my position is well-known). Something has to be done though. Progress needs to be made, and to make progress we must have a clear understanding of how we should proceed. Tiles will not work as expected with modules and that needs to be fixed. What form should it take? I'm tired of speculation. I'm happy to study Tiles and determine what needs to change, but I will not take the decision of how to implement it upon myself. Please bear in mind that we have folks waiting on 1.1F very anxiously and that any behavior can be rectified in a later release. Also note that refactoring to support a dependent configuration would not undo (that I can see) any change which would be required to make the configurations entirely independent. That is a necessary step. The only question is if/when the next step of allowing sharing across modules should occur. Cast your vote. [ ] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [ ] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. [ ] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by a switch which defaults to off [ ] I want tiles to have a different configuration (Elaborate). -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] How should Tiles be refactored?
Could we have a ruling on this, please? As far as I can tell, it's still Thursday, in all parts of the world. ;) -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:14 PM To: Struts Developers List Subject: RE: [VOTE] How should Tiles be refactored? Well, I know I'm not a committer and all hanging-head, but for what its worth... [ ] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [ ] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. [ x ] I DON'T think we should allow naked pictures of the committers on the main pageDOH HAHAHAHA [ ] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by a switch which defaults to off [ ] I want tiles to have a different configuration (Elaborate). James ...and you thought I was serious for a sec huh? Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:49 PM To: Struts Developers List Subject: [VOTE] How should Tiles be refactored? There's been a lot of discussion on how 1.1 final should look, and I think it's good to have such discussions. We (commiters and non), being tasked with implementing everything that is Struts 1.1, need to have a clear picture of exactly what that means. Now, when it gets right now to brass tacks, it's irrelevant to me which way we go on this (right now - I think my position is well-known). Something has to be done though. Progress needs to be made, and to make progress we must have a clear understanding of how we should proceed. Tiles will not work as expected with modules and that needs to be fixed. What form should it take? I'm tired of speculation. I'm happy to study Tiles and determine what needs to change, but I will not take the decision of how to implement it upon myself. Please bear in mind that we have folks waiting on 1.1F very anxiously and that any behavior can be rectified in a later release. Also note that refactoring to support a dependent configuration would not undo (that I can see) any change which would be required to make the configurations entirely independent. That is a necessary step. The only question is if/when the next step of allowing sharing across modules should occur. Cast your vote. [ ] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [ ] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. [ ] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by a switch which defaults to off [ ] I want tiles to have a different configuration (Elaborate). -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] How should Tiles be refactored?
You sure about that? ;) James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org -Original Message- From: Karr, David [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 6:18 PM To: 'Struts Developers List' Subject: RE: [VOTE] How should Tiles be refactored? Could we have a ruling on this, please? As far as I can tell, it's still Thursday, in all parts of the world. ;) -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:14 PM To: Struts Developers List Subject: RE: [VOTE] How should Tiles be refactored? Well, I know I'm not a committer and all hanging-head, but for what its worth... [ ] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [ ] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. [ x ] I DON'T think we should allow naked pictures of the committers on the main pageDOH HAHAHAHA [ ] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by a switch which defaults to off [ ] I want tiles to have a different configuration (Elaborate). James ...and you thought I was serious for a sec huh? Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:49 PM To: Struts Developers List Subject: [VOTE] How should Tiles be refactored? There's been a lot of discussion on how 1.1 final should look, and I think it's good to have such discussions. We (commiters and non), being tasked with implementing everything that is Struts 1.1, need to have a clear picture of exactly what that means. Now, when it gets right now to brass tacks, it's irrelevant to me which way we go on this (right now - I think my position is well-known). Something has to be done though. Progress needs to be made, and to make progress we must have a clear understanding of how we should proceed. Tiles will not work as expected with modules and that needs to be fixed. What form should it take? I'm tired of speculation. I'm happy to study Tiles and determine what needs to change, but I will not take the decision of how to implement it upon myself. Please bear in mind that we have folks waiting on 1.1F very anxiously and that any behavior can be rectified in a later release. Also note that refactoring to support a dependent configuration would not undo (that I can see) any change which would be required to make the configurations entirely independent. That is a necessary step. The only question is if/when the next step of allowing sharing across modules should occur. Cast your vote. [ ] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [ ] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. [ ] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by a switch which defaults to off [ ] I want tiles to have a different configuration (Elaborate). -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] How should Tiles be refactored?
Oh. Sheesh, it's not even Thursday. -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:22 PM To: Struts Developers List Subject: RE: [VOTE] How should Tiles be refactored? You sure about that? ;) James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org -Original Message- From: Karr, David [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 6:18 PM To: 'Struts Developers List' Subject: RE: [VOTE] How should Tiles be refactored? Could we have a ruling on this, please? As far as I can tell, it's still Thursday, in all parts of the world. ;) -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:14 PM To: Struts Developers List Subject: RE: [VOTE] How should Tiles be refactored? Well, I know I'm not a committer and all hanging-head, but for what its worth... [ ] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [ ] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. [ x ] I DON'T think we should allow naked pictures of the committers on the main pageDOH HAHAHAHA [ ] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by a switch which defaults to off [ ] I want tiles to have a different configuration (Elaborate). James ...and you thought I was serious for a sec huh? Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:49 PM To: Struts Developers List Subject: [VOTE] How should Tiles be refactored? There's been a lot of discussion on how 1.1 final should look, and I think it's good to have such discussions. We (commiters and non), being tasked with implementing everything that is Struts 1.1, need to have a clear picture of exactly what that means. Now, when it gets right now to brass tacks, it's irrelevant to me which way we go on this (right now - I think my position is well-known). Something has to be done though. Progress needs to be made, and to make progress we must have a clear understanding of how we should proceed. Tiles will not work as expected with modules and that needs to be fixed. What form should it take? I'm tired of speculation. I'm happy to study Tiles and determine what needs to change, but I will not take the decision of how to implement it upon myself. Please bear in mind that we have folks waiting on 1.1F very anxiously and that any behavior can be rectified in a later release. Also note that refactoring to support a dependent configuration would not undo (that I can see) any change which would be required to make the configurations entirely independent. That is a necessary step. The only question is if/when the next step of allowing sharing across modules should occur. Cast your vote. [ ] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [ ] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. [ ] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by a switch which defaults to off [ ] I want tiles to have a different configuration (Elaborate). -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] How should Tiles be refactored?
Ya, sorryI couldnt resist. James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org -Original Message- From: Karr, David [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 6:24 PM To: 'Struts Developers List' Subject: RE: [VOTE] How should Tiles be refactored? Oh. Sheesh, it's not even Thursday. -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:22 PM To: Struts Developers List Subject: RE: [VOTE] How should Tiles be refactored? You sure about that? ;) James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org -Original Message- From: Karr, David [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 6:18 PM To: 'Struts Developers List' Subject: RE: [VOTE] How should Tiles be refactored? Could we have a ruling on this, please? As far as I can tell, it's still Thursday, in all parts of the world. ;) -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:14 PM To: Struts Developers List Subject: RE: [VOTE] How should Tiles be refactored? Well, I know I'm not a committer and all hanging-head, but for what its worth... [ ] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [ ] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. [ x ] I DON'T think we should allow naked pictures of the committers on the main pageDOH HAHAHAHA [ ] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by a switch which defaults to off [ ] I want tiles to have a different configuration (Elaborate). James ...and you thought I was serious for a sec huh? Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:49 PM To: Struts Developers List Subject: [VOTE] How should Tiles be refactored? There's been a lot of discussion on how 1.1 final should look, and I think it's good to have such discussions. We (commiters and non), being tasked with implementing everything that is Struts 1.1, need to have a clear picture of exactly what that means. Now, when it gets right now to brass tacks, it's irrelevant to me which way we go on this (right now - I think my position is well-known). Something has to be done though. Progress needs to be made, and to make progress we must have a clear understanding of how we should proceed. Tiles will not work as expected with modules and that needs to be fixed. What form should it take? I'm tired of speculation. I'm happy to study Tiles and determine what needs to change, but I will not take the decision of how to implement it upon myself. Please bear in mind that we have folks waiting on 1.1F very anxiously and that any behavior can be rectified in a later release. Also note that refactoring to support a dependent configuration would not undo (that I can see) any change which would be required to make the configurations entirely independent. That is a necessary step. The only question is if/when the next step of allowing sharing across modules should occur. Cast your vote. [ ] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [ ] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. [ ] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by a switch which defaults to off [ ] I want tiles to have a different configuration (Elaborate). -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands
RE: [VOTE] How should Tiles be refactored?
Back to the issue at hand, though: Why can't tiles have a global configuration that can be overidden locally? Is this feasible? Other environments offer such functionality. -Daniel -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 6:26 PM To: Struts Developers List Subject: RE: [VOTE] How should Tiles be refactored? Ya, sorryI couldnt resist. James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org -Original Message- From: Karr, David [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 6:24 PM To: 'Struts Developers List' Subject: RE: [VOTE] How should Tiles be refactored? Oh. Sheesh, it's not even Thursday. -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:22 PM To: Struts Developers List Subject: RE: [VOTE] How should Tiles be refactored? You sure about that? ;) James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org -Original Message- From: Karr, David [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 6:18 PM To: 'Struts Developers List' Subject: RE: [VOTE] How should Tiles be refactored? Could we have a ruling on this, please? As far as I can tell, it's still Thursday, in all parts of the world. ;) -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:14 PM To: Struts Developers List Subject: RE: [VOTE] How should Tiles be refactored? Well, I know I'm not a committer and all hanging-head, but for what its worth... [ ] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [ ] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. [ x ] I DON'T think we should allow naked pictures of the committers on the main pageDOH HAHAHAHA [ ] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by a switch which defaults to off [ ] I want tiles to have a different configuration (Elaborate). James ...and you thought I was serious for a sec huh? Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:49 PM To: Struts Developers List Subject: [VOTE] How should Tiles be refactored? There's been a lot of discussion on how 1.1 final should look, and I think it's good to have such discussions. We (commiters and non), being tasked with implementing everything that is Struts 1.1, need to have a clear picture of exactly what that means. Now, when it gets right now to brass tacks, it's irrelevant to me which way we go on this (right now - I think my position is well-known). Something has to be done though. Progress needs to be made, and to make progress we must have a clear understanding of how we should proceed. Tiles will not work as expected with modules and that needs to be fixed. What form should it take? I'm tired of speculation. I'm happy to study Tiles and determine what needs to change, but I will not take the decision of how to implement it upon myself. Please bear in mind that we have folks waiting on 1.1F very anxiously and that any behavior can be rectified in a later release. Also note that refactoring to support a dependent configuration would not undo (that I can see) any change which would be required to make the configurations entirely independent. That is a necessary step. The only question is if/when the next step of allowing sharing across modules should occur. Cast your vote. [ ] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [ ] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. [ ] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off
RE: [VOTE] How should Tiles be refactored?
I want to stay on this list but the volume of emails is getting a bit high and I have work to do. I would appreciate it if emails that aren't adding information to a thread were taken off list. It's nice to monitor the list to keep tabs on what's going on but the quality of the traffic has declined recently. The fact that there is lots of activity recently is good but we don't need to hear from everyone unless they have something substantive to add. No need to respond to this. If you agree, thanks, if not, keep sending email whenever you feel like it and I will just set up a rule. -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:14 PM To: Struts Developers List Subject: RE: [VOTE] How should Tiles be refactored? Well, I know I'm not a committer and all hanging-head, but for what its worth... [ ] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [ ] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. [ x ] I DON'T think we should allow naked pictures of the committers on the main pageDOH HAHAHAHA [ ] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by a switch which defaults to off [ ] I want tiles to have a different configuration (Elaborate). James ...and you thought I was serious for a sec huh? Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:49 PM To: Struts Developers List Subject: [VOTE] How should Tiles be refactored? There's been a lot of discussion on how 1.1 final should look, and I think it's good to have such discussions. We (commiters and non), being tasked with implementing everything that is Struts 1.1, need to have a clear picture of exactly what that means. Now, when it gets right now to brass tacks, it's irrelevant to me which way we go on this (right now - I think my position is well-known). Something has to be done though. Progress needs to be made, and to make progress we must have a clear understanding of how we should proceed. Tiles will not work as expected with modules and that needs to be fixed. What form should it take? I'm tired of speculation. I'm happy to study Tiles and determine what needs to change, but I will not take the decision of how to implement it upon myself. Please bear in mind that we have folks waiting on 1.1F very anxiously and that any behavior can be rectified in a later release. Also note that refactoring to support a dependent configuration would not undo (that I can see) any change which would be required to make the configurations entirely independent. That is a necessary step. The only question is if/when the next step of allowing sharing across modules should occur. Cast your vote. [ ] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [ ] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. [ ] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by a switch which defaults to off [ ] I want tiles to have a different configuration (Elaborate). -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] How should Tiles be refactored?
Having a tough week David? - Original Message - From: Karr, David [EMAIL PROTECTED] Oh. Sheesh, it's not even Thursday. -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED]] You sure about that? ;) -Original Message- From: Karr, David [mailto:[EMAIL PROTECTED]] Could we have a ruling on this, please? As far as I can tell, it's still Thursday, in all parts of the world. ;) -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED]] Well, I know I'm not a committer and all hanging-head, but for what its worth... [ x ] I DON'T think we should allow naked pictures of the committers on the main pageDOH HAHAHAHA -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] How should Tiles be refactored?
Nope, I was just in a time warp. EOT. -Original Message- From: David Derry [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 4:49 PM To: Struts Developers List Subject: Re: [VOTE] How should Tiles be refactored? Having a tough week David? - Original Message - From: Karr, David [EMAIL PROTECTED] Oh. Sheesh, it's not even Thursday. -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED]] You sure about that? ;) -Original Message- From: Karr, David [mailto:[EMAIL PROTECTED]] Could we have a ruling on this, please? As far as I can tell, it's still Thursday, in all parts of the world. ;) -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED]] Well, I know I'm not a committer and all hanging-head, but for what its worth... [ x ] I DON'T think we should allow naked pictures of the committers on the main pageDOH HAHAHAHA -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
