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]>
