I was thinking about this in the car - Struts now has a new set of customers- the seething masses of non-J2EE sanctioned view technologies for webapps
:) More inline... On 2/13/02 7:35 AM, "Ted Husted" <[EMAIL PROTECTED]> wrote: > "Geir Magnusson Jr." wrote: >> 1) Why isn't this stuff on the jakarta struts site, in a sandbox or contrib >> area? > > It was taken out temporarily when the support for modular applications > was added. I haven't had a chance to put it back in yet. The support for > modular applications introduced a new base object that I can now extend. > > Cool! > >> 2) It sounds to me like you are declaring what you are going to do - your >> mind is made up. > > Yes, I have decided that the Struts controller should provide better > support for presentation layers, and will be spending my volunteer hours > working toward that end. > > If people want to take advantage of this feature, I'm always happy to > collaborate. > > If people want to go a different way, I'll be happy to provide whatever > information I can. I guess my point is along the lines above - you now have a new set of 'customers', ones that are willing to participate in the development. Also, my issue isn't about what you are spending your volunteer hours doing, which is great and should be what you want, but more along the lines of not then making it the only solution to the problem. Not that I am advocating direct support for every kind of view layer known, but maybe establishing as flexible an 'access contract' as possible that the templating wierdo's like us can write to, and not worry that you will change it on a whim... > > >> Gabriel was pretty successful, and I assume Nathan as well, in beginning >> from their own starting point and achieving a solution. I am interested in >> looking at Nathans as he wasn't a struts or JSP guy - he was a Velocity user >> coming at it from the viewpoint of just needing the functionality of the >> controller and the resources it exposed. > > As I remember, Gabriel's initial work was based on the ContextHelper. > After spending several long hours in email exchanges like this, I begged > off and you and Gabriel finished up on your own. At this point, I'm > presenting the opportunity to merge this initative with the Struts > development stream. But, if developers choose to pursue other avenues, > that's their perogative. I'll continue to provide whatever technical > support I can. Well, I think Gabriel on his own initiative took the independent approach before you begged off... > > > >> I assume neither depended upon the One True Tool presented by the controller >> to do it since there is none. The fact that they could do it that way is a >> pretty strong endorsement of what Struts does now, and maybe something could >> be taken from that as you change it. >> >> I am also worried that you are going to close the door to unconventional >> view layers if you nail down the resource contract in a tool provided by >> yourself... > > All that I am saying is that there is and will be an API object in the > request that a "tool" can choose to use. There would be nothing to > prevent a helper servlet from ignoring that object and gaining direct > access to the same resources, and expose those resources to its tools in > any way it chooses. Will Struts formalize a 'contract' with those resources, or is it "Use our tool or you are screwed..." That's all I'm worried about. Also, what happens if I want to use the struts controller outside of a webapp? Will that be possible? > > It's important to remember that I am not concerned only with Velocity, > but with all presentation layers, including JSTL, XLST, et cetera. If > people want work work on a Velocity-specific solution, that's their > perogative. If people want to collaborate on a shared API object, even > better. I agree 100%. I just don't think it necessarily has to be a single API object, but more like a definition about where things will be that all users can get to. If it can be decoupled from the Servlet API, so much the better, I think. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Age and treachery will always triumph over youth and talent -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
