on 9/12/2000 1:21 PM, "Magn�s ?�r Torfason" <[EMAIL PROTECTED]> wrote: > Well, I'm not very well accuainted with WebMacro, and it might be easy to > accomplish with templates, but I've developed an application for WML using > screens, and found some limitations. > > Problem: The biggest is that org.apache.ecs.Document, the container of all > the stuff in the page, is very HTML oriented ( method setHtml(Html > set_html) ). I did not see how the <html></html> tags that result from this > method can be avoided in a neat way. I subclassed org.apache.ecs.html.Html > with my very own WML element, and output the mandatory header in a subclass > of Layout. See source at bottom of page. > Solution: Not very easy, seems to me that this would require creating a > markup-language independent document class and modifying RunData to use that > class instead of Document Gag. What is wrong with just defining your own Layout? > Problem: When a redirection is neccessary a text/html document (with a > redirection header, 302 i believe) straight from Turbine servlet. This > works with some wap devices, but not with others. > Solution: Modifying Turbine, one possibility is to put in a conditional > processing based on the request (redirect, or output legal wml to instruct > the browser to check the new page), or modularizing the redirection > handling, possibly with a Redirection class, with the function > processRedirect(HttpResponse res, String redirectionUrl). This contains > some overhead, and would need to be Screen dependent, because: huh? > Problem: I would like to run the WML frontend in the same instance as the > regular Html frontend. This requires screen dependent redirection handling, > and, the ability to specify a Login Screen in the request, since the default > login screen obviously is legal for only one of the content types. > Solution: Add a mechanism in Turbine.java to allow screen variables to be > really used, instead of always pointing to the one specified in > TurbineResources.properties. This would of course create a security > loophole, but could be countered with a boolean isScreenLoginScreen() > function in Screen, returning false, but allowing login screens to subclass > the function to return true. -1...this isn't needed you can code around these issues without problems by defining your own Layout. > I would be prepared to contribute to the tree if people like these changes, > but if people do not, I will go on using hacks not requiring modifications > to the core Turbine code, since that will lessen the work maintaining my > app. don't hack things, but instead either replace the functionality by overriding the existing default behavior of it. -jon -- http://scarab.tigris.org/ | http://noodle.tigris.org/ http://java.apache.org/ | http://java.apache.org/turbine/ http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/ http://www.collab.net/ | http://www.sourcexchange.com/ ------------------------------------------------------------ To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/> Problems?: [EMAIL PROTECTED]
