This statement was poorly phrased and caused you to miss my point. I am not concerned that other approaches do or don't allow things like a jsp scriptlet. I really am concerned about two things. First, and my main point, is that Struts doesn't do a very good job of helping non-technical web designers. Secondly, other approaches introduce proprietary concepts to solve their problems. For example, the XMLC approach is using the ID attribute in a proprietary way to mean something other than what it was initially defined for. By the way, since the ID's have to be unique (since that is what their intent was in the first place), it seems that it would be difficult to refer to the same object in two place on a page without duplicating something on the back end.
I like the Struts concept, just wish we were better integrated into presentation development systems. bob ----- Original Message ----- From: "Dan Cancro" <[EMAIL PROTECTED]> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> Sent: Thursday, May 02, 2002 4:30 PM Subject: RE: XMLC Article on the Serverside > Could you elaborate on the particular ways "power and flexibility of > standard implementation approaches" must be sacrificed by using something > other than jsp's. I think you're talking about being able to enter > scriptlets in emergencies. Could you describe the particular cases when you > could not do something in an alternative presentation language that you can > with a jsp scriptlet? > > > Thanks, > Dan > > > -----Original Message----- > > From: Robert Williams [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, May 02, 2002 2:17 PM > > To: Struts Users Mailing List > > Subject: Re: XMLC Article on the Serverside > > > > > > I have been looking at a lot different approaches for > > developing web pages > > (and/or other formats). The one thing the "anti-JSP" folks > > seem to have in > > common is that they find it too difficult for non-technical > > designers to > > deal with the tag format, and what appears to be complex > > concepts like Java > > Beans or data objects. The various alternatives are always > > trying to make > > the front end development easier. In some respects I agree, but that > > doesn't mean you should give up the power and flexibility of standard > > implementation approaches. There is a lot of power with JSP > > for those who > > want to use it and I don't want to give up this flexibility > > to use it when I > > need to. > > > > Taglibs help some, along with frameworks such as Struts. > > However, there are > > few web page development environments (I have only found one > > good one - > > Dreamweaver UltraDev) that does a reasonable job of assisting with the > > development of web pages using custom Taglibs. This is > > possible with the > > extension provided in the common/taglibs section of this web site. > > > > I feel one area this group should be working on is the > > development of tools > > to ease the front end development. I like the tiles concept > > and will use > > it, but does this make the front end development too > > abstract? The Struts > > folks have done a good job of making the server side > > development environment > > well organized. Any thoughts on working more on the front > > end so we can get > > designers to use this technology and so we can easily support > > XML as easily > > as we support HTML? The basics are in place as I have not > > seen anything is > > other environments that is not here and I think the Struts > > environment is > > better on the server side than most. > > > > Thoughts? > > > > bob > > ----- Original Message ----- > > From: "Dan Cancro" <[EMAIL PROTECTED]> > > To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> > > Sent: Thursday, May 02, 2002 3:36 PM > > Subject: RE: XMLC Article on the Serverside > > > > > > > Thanks, > > > > > > So to wrap up this thread, I think this summarizes the > > article's points: > > > > > > XMLC > > > -generates a file from a source file > > > -requires engineer and designer to use a common set of id names > > > > > > > > > > > > > -----Original Message----- > > > > From: Pedone, Tim [mailto:[EMAIL PROTECTED]] > > > > Sent: Thursday, May 02, 2002 12:47 PM > > > > To: 'Struts Users Mailing List' > > > > Subject: RE: XMLC Article on the Serverside > > > > > > > > > > > > Here's an article comparing Velocity and XMLC. It points out > > > > some of the > > > > short comings of XMLC so it is somewhat relavent. Of course > > > > you can use > > > > Velocity with Struts too. > > > > > > > > http://jakarta.apache.org/velocity/casestudy2.html > > > > > > > > -----Original Message----- > > > > From: Dan Cancro [mailto:[EMAIL PROTECTED]] > > > > Sent: Thursday, May 02, 2002 11:36 AM > > > > To: '[EMAIL PROTECTED]' > > > > Subject: FW: XMLC Article on the Serverside > > > > > > > > > > > > I thought the Struts users on this list might be interested > > > > in this article > > > > about XMLC vs. JSP. > > > > > > > > It's pretty pro-XMLC. I couldn't find any contrary opinions > > > > in the Struts > > > > archive. Does anyone know some disadvantages of XMLC > > compared to JSP? > > > > > > > > Thanks, > > > > Dan > > > > > > > > > > > > > > > > > > > > http://www.theserverside.com/resources/article.jsp?l=XMLCvsJSP > > > > > > > > > > > > -- > > > > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
