Re: App Design
ok, the link is rather old, and maybe also a bit dogmatic: But most of it still holds true. Apart from the usability-hassles described in the link, in my experience you can add a bunch of problems you get when you try to generate your frames programmatically (the simplest one being the requirement to generate a link to the preceding page(whatever that means when you use frames) that also had to work when javascript is deactivated - the history.back() at last works halfway consistent for almost all browsers, but it took them a while...) - then you have the problem with deep-links into the site (you almost always end up with an xml-file that contains the complete site-layout and from which you can generate right frameset - almost always buggy and hard to maintain...), synching data in different frames (using an equally bad mixture of javascript/sevlet-code...). There are some applications out there which almost all have to something with configuration (configuring a new car, a new pc and so on) which make heavy use of javascript and frames to maintain the state of the configuration: Although i agree that there almost always a whole lot of data flows from and to the browser, which can/should be cached in frames, in reality these configrurators almost always seem to be crashing short before purchasing your new car, which took you about an hour to configure... so, no, i don't see any real reason for using frames for other things than doing some static designer-portfolio-pages (but i think they are currently overusing flash for this purpose...) ps: excuse me for this elaborate rage, but i have been burnt before in projects where i was forced to use frames - Original Message - From: Keith [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Wednesday, February 13, 2002 10:25 AM Subject: Re: App Design Is there a good argument for using frames? It needs to be good, they obviously are problematic to use. Beware the page linked to below is dated Dec. 1996 - most of what's in it is obsolete! --- stf [EMAIL PROTECTED] wrote: frames suck: I don't think it's a good idea to separate your page-flow onto two different layers, one being the javscript/frame-constellation, the other the struts config-files. What exactly are you trying to achive? If you just want to reuse your navigation, then go for some kind of template-engine(e.g. tiles, even simple, maybe parametrized includes will be better than frames..) - if you have a designer, who insists, that frames are more usable or just look better, have him read this: http://www.useit.com/alertbox/9612.html - it's already so old that i thought, everybody knows it by now ;) - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 12, 2002 9:10 PM Subject: App Design Hi all, I am thinking of structuring an application as follows, and would appreciate any advice and ideas of how to do this: There will be two frames. First is a navigation frame where the user presses a button to determine the JSP that is loaded into the second frame. Each possible JSP for the second frame will have form. If a user is entering data into the form, and then presses a button on the navigation frame to go to a different jsp/form, I want to save the partially entered form data from the page the user is leaving. Then when the user goes back to the first page they can continue where they left off. I have been prototyping an idea; the navigation frame uses JavaScript to submit the form and redirect the old page to the new desired page. So far I have accomplished that when the form is submitted the action does not really do anything, so the form data is saved in the bean. But how do I accomplish the redirect? Any ideas are greatly appreciated. Mark Glatzer *** Disclaimer This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and/or CONFIDENTIAL or both. This email is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this email is not an intended recipient, you have received this email in error and any review, dissemination, distribution or copying is strictly prohibited. If you have received this email in error, please notify the sender immediately by return mail and permanently deleting the copy you received. Thank you. *** -- 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: help: %.. how do i convince them to learn JSP?
I think it depends on, what you're trying to achieve: If i remember it corrctly, the tags inside the jsp get inlined when the jsp is compiled: So the performance problem boils down to a problem of objectcreation and -deletion, which nowadays is handled quite good by most modern jvm. If you want to fetch labels from property-files, then the properties are cached in a per-jvm manner. If you really run into performance issues, i don't think they come from using taglibs but from the requirement to mix-in the labels dynamically (maybe to perform internationaliation or - even worse - based on user-rights or preferences): So maybe you should try to think of some sort of pre-processing (generating templates with the right labels in it and then using a simple template-engine or maybe even simple bean-tags(%=..%) to populate the pages. And maybe you should have someeone think about the requirement for exposing ten thousands of users to 50 -100 elements on just one page - has to be a very special audience...;) - Original Message - From: Bob Williams [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Tuesday, February 12, 2002 4:05 PM Subject: Re: help: %.. how do i convince them to learn JSP? I have no problem being convinced that tags should be used for generating complex items on a web page. The one concern I do have, relative to using tags, is the extra processing required to generate simple things. I have seen pages in industrial environments where the page may have 50-100 elements displayed (and no this is not a problem with the design this is a real application requirement!). Using a tag to generate labels and text input boxes seems like it would add a significant compute load on a server that is servicing 100's of people. The same situation applies when you are dealing with pages with fewer elements, but are being served up to 1000's or 10,000's of users. Does anyone have experience about computing resources required by tags in these types of scenarios? bob - Original Message - From: Sarah Farrell [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Monday, February 11, 2002 9:48 PM Subject: Re: help: %.. how do i convince them to learn JSP? Michael, Here's the best one I could find. http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/ web_tier/qanda/index.html There are some other ones on java.sun.com if you search for JSP presentation logic separate. Here's another one: http://java.sun.com/products/jsp/ P.S. Please don't cross-post to multiple jakarta lists. At 07:34 PM 2/11/2002 -0800, you wrote: long before server pages or servlets existed i was writing these C++ template based systems with CGI so i could do my best to separate content generation from programming logic... i'm a consultant and this company made me lead on my first JSP/Servlet based project, i was really excited to get involved with JSP tag libraries. but when i got into the code base IT'S ALL .jsp files with TONS of Java scriptlets! it's nasty. if/else blocks several hundred lines long. the developer i took this over from thinks there is no reason to do it any other way. tags? why use tags? i am asking for input/references on why you want to keep the scriptlets % /% out of the JSP files. every time i try to make a point-- maybe i'm just not being eloquent enough... on another note: is it really model 2 if a JSP is processing the request? i don't think it is, even if your entire JSP is just some java code wrapped with a scriptlet tag.. (yuk). thanks for input. --Michael -- 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: Editing a database record best practice?
we are using a similar approach with ejb's, that produce value object's instead of database records: We have generic ValueObjects that are filled into the formBean using reflection (You can do something similar with result-sets using the meta-data: as long as you don't mind tying your bean-properties to the database-field names...): along with the data, a timestamp is transported inside the value-object: So only the ValueObject with the last timestamp can make an update on the ejb (with only some exceptions (CLOb/BLOB-fields which get specific update methods) we make global updates, we just set *all* values from the value-object into the ejb. Coming back from the form the process works the other way round: copying the values from the ActionForm into the valueObject and then passing it to the ejb for update... This sounds like a lot of copying: We first had the ejb's producing ValueObjects that extended action-forms with all the fields needed in the form: we ended up with having to package the struts-libs with every EJB caused by this mixing of business-object and view-layer (resulting in a lot of classloading-hassle: Fortunately you sometimes get real errors for bad design-decisions..) - so we ended up with this generic ValueObjectLayer that clearly separates the view from the Business-objects. Instead of using ejb you can try jdo (e.g castor, or intelliBO) - I'm not really sure, wether the need for such a neutralizing layer vanishes with this, but I think they will give you at least some handy tools to write the Data-Access-layer without having to write the sql by yourself. greetings stf - Original Message - From: Ryan Cornia [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 12, 2002 2:56 AM Subject: Editing a database record best practice? A common scenario I run into is having a web application where the user needs to edit a database record. The simplest approach I can find is this - 1.) Load the db record into a bean. Copy the bean props. to the form for display. Put the dbbean in the session. 2.) Show the form, when the user presses save, validate the form, make sure, if possible, that the form primary key fields are equal to the dbbean in the session primary fields. 3.) Have the dbbean do an update statement. In order to do this properly, the dbbean needs to have kept the original db values so they can be put in a where clause. This insures that we are changing the record exactly as we loaded it. If somone made a change before the page was submitted, the update would fail. Is that the best approach to accomodate a sort of optomistic locking? Are there any tools to autogenerate the dbbean objects? I was thinking of trying to do it with an xml schema and XSLT to transform the schema to java objects. Thoughts? Thanks, Ryan -- 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: Editing a database record best practice?
Is this really an issue?! if you pass a from object from server to server, it shouldn't be much more than the fields it contains - so it makes absolutely no difference how much code you have around your data - no matter in what structure you keep them (or do you mean that it is an issue of memory - as the Form-object will be recreated in the midle tier: along with everything needed only in the view-tier...) But if you do (as we do) the conversion from form to value-object and vice-versa in the Action: This way the Form never leaves the presentation-tier and the Value-Objects are as simple and dumb as they can be...: This works very well for simple EntityBeans, which we access directly from the Action, but it even works with more complex Value-Objects that finally work on several EntityBeans: We just facade them with a stateless-session-Bean, which sorts the values and drops them in the right EntityBeans. This even scales on clusters, as you can separate servlet/jsp, the ejb-container and the database on different machines... - Original Message - From: Adam Hardy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 12, 2002 6:49 PM Subject: Re: Editing a database record best practice? On Tue, 12 February 2002, Jonathan Gibbons wrote: I guess the really OTT answer is: User/GUI = Form Object, all strings Mid Tier = Value object holding equivalent fields for each form field, but in native data type, but no struts code. DB = EJB, local interfaces. OTT as in the case of an app which you know you're going to deploy on a webfarm? In which case the DB will probably be on a seperate server, the webservers on another, possibly with EJB on board, possibly EJBs on their own server? The technical issue is whether you can realistically pass a form object from a performance point of view from one server to another. Find the best deals on the web at AltaVista Shopping! http://www.shopping.altavista.com -- 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: App Design
frames suck: I don't think it's a good idea to separate your page-flow onto two different layers, one being the javscript/frame-constellation, the other the struts config-files. What exactly are you trying to achive? If you just want to reuse your navigation, then go for some kind of template-engine(e.g. tiles, even simple, maybe parametrized includes will be better than frames..) - if you have a designer, who insists, that frames are more usable or just look better, have him read this: http://www.useit.com/alertbox/9612.html - it's already so old that i thought, everybody knows it by now ;) - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 12, 2002 9:10 PM Subject: App Design Hi all, I am thinking of structuring an application as follows, and would appreciate any advice and ideas of how to do this: There will be two frames. First is a navigation frame where the user presses a button to determine the JSP that is loaded into the second frame. Each possible JSP for the second frame will have form. If a user is entering data into the form, and then presses a button on the navigation frame to go to a different jsp/form, I want to save the partially entered form data from the page the user is leaving. Then when the user goes back to the first page they can continue where they left off. I have been prototyping an idea; the navigation frame uses JavaScript to submit the form and redirect the old page to the new desired page. So far I have accomplished that when the form is submitted the action does not really do anything, so the form data is saved in the bean. But how do I accomplish the redirect? Any ideas are greatly appreciated. Mark Glatzer *** Disclaimer This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and/or CONFIDENTIAL or both. This email is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this email is not an intended recipient, you have received this email in error and any review, dissemination, distribution or copying is strictly prohibited. If you have received this email in error, please notify the sender immediately by return mail and permanently deleting the copy you received. Thank you. *** -- 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: Server Side Browser Sniffer
there exists a commercial version of a browser-sniffer, which comes as a JavaBean(http://www.cyscape.com/products/bhawk/javabean.asp): It has quite an impressive list of features which can serve as a guideline for the development However, it should not stop a the bean, tags would be nice: And a heavy integration with struts (and especially with the jsptl) would also be nice: e.g. use the user-agent inside logic-tags or determine whichstylesheet to use for a given agent - Original Message - From: Robert Taylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 27, 2002 1:54 PM Subject: Server Side Browser Sniffer Greetings, I'm currently integrating Struts into our existing web application and thought that I would take advantage of filters to sniff out the browser version and other information contained in the user-agent request header. I looked at the Ultimate Browser Sniffer (http://www.mozilla.org/docs/web-developer/sniffer/browser_type.html) and thought it would be useful to have a server side version, call it BrowserSniffer which provides an API similar to the Ultimate Browser Sniffer (isIEUp(), isNav(), etc...). The filter would first check to see if BrowserSniffer was in the current user session. If not, it would create a BrowserSniffer with the user-agent request header and place it in the session. A custom tag or a set of tags (or scriplets; blasphemy! :) ) could be used to extract information from BrowserSniffer to determine the appropriate presentation logic. I'm assuming there would be an advantage to this because the parsing of the user-agent field would occur once per user session unlike the Javascript version which needs to parse the user-agent field on each page that is rendered, not to mention that it must be included on every page. So, has anyone attempted this before or does there already exist an open source solution or do people pretty much just stick with the client side solution. Thanks, robert -- 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: Tools for Building Web Services (fwd)
Have you seen that apache has completeley re-written apache SOAP, which is now called Axis and has a whole bunch of new features (like wsdl2java and java2wsdl, an instant deployment-feature called jws (java-web-service) - they also promise a heavy increase in performance, as they have switched from dom to sax (although i have not checked out, wether it is really that much faster than before) - so it now looks almost similar to GLUE - has anybody used it in a production enviroment yet?+ACE- greetings Stefan - Original Message - From: +ACI-Jon Ferguson+ACI- +ADw-ferguson+AEA-ieee.org+AD4- To: +ACI-Struts Users Mailing List+ACI- +ADw-struts-user+AEA-jakarta.apache.org+AD4- Sent: Sunday, January 27, 2002 4:35 PM Subject: Re: Tools for Building Web Services (fwd) +AD4- Hey Guys, +AD4- +AD4- Along these lines, have a look at www.themindelectric.com they have a cool +AD4- web-services development platform called GLUE which is +AD4- extremely easy to use... what's more they can send messages using their XML +AD4- parser about 3x faster than apache. +AD4- +AD4- I'm planning to use webservices in my current project so I'd for one be +AD4- interested in how people are doing mixing it with Struts... +AD4- +AD4- Cheers, +AD4- Jon +AD4- +AD4- +ACI-Craig R. McClanahan+ACI- wrote: +AD4- +AD4- +AD4- If you are interested in developing Web Services, you will be interested +AD4- +AD4- in the Java Web Services Developer Pack (version 1.0ea1) that was just +AD4- +AD4- released by Sun: +AD4- +AD4- +AD4- +AD4- http://java.sun.com/webservices +AD4- +AD4- +AD4- +AD4- The Java WSDP includes early releases of base XML technology: JAXP 1.2 +AD4- +AD4- (with schema support), SOAP-based RPC (JAX-RPC), SOAP-based messaging +AD4- +AD4- (JAXM), and registry client support (JAXR). Although this is an EA1 +AD4- +AD4- release of the product we are targeting for this summer, we also include a +AD4- +AD4- tutorial as well as a number of development features to help you get up +AD4- +AD4- and running quickly, including building tools (Apache's Ant), a UDDI based +AD4- +AD4- registry server for testing, some management tools (more in later EAs). +AD4- +AD4- We also include a version of Apache Tomcat so develoeprs can start using +AD4- +AD4- the JWSDP right away. All of these technologies depend on J2EE 1.3 APIs. +AD4- +AD4- +AD4- +AD4- (And, of course, it runs Struts based apps just fine and dandy also :-) +AD4- +AD4- +AD4- +AD4- Craig McClanahan +AD4- +AD4- +AD4- +AD4- -- +AD4- +AD4- To unsubscribe: ++ADw-mailto:tomcat-user-unsubscribe+AEA-jakarta.apache.org+AD4- +AD4- +AD4- For additional commands: ++ADw-mailto:tomcat-user-help+AEA-jakarta.apache.org+AD4- +AD4- +AD4- Troubles with the list: ++ADw-mailto:tomcat-user-owner+AEA-jakarta.apache.org+AD4- +AD4- +AD4- +AD4- +AD4- -- +AD4- +AD4- To unsubscribe, e-mail: +ADw-mailto:struts-user-unsubscribe+AEA-jakarta.apache.org+AD4- +AD4- +AD4- For additional commands, e-mail: +ADw-mailto:struts-user-help+AEA-jakarta.apache.org+AD4- +AD4- +AD4- +AD4- -- +AD4- To unsubscribe, e-mail: +ADw-mailto:struts-user-unsubscribe+AEA-jakarta.apache.org+AD4- +AD4- For additional commands, e-mail: +ADw-mailto:struts-user-help+AEA-jakarta.apache.org+AD4- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
