struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith <keithbaconstr...@yahoo.com>
Subject Re: App Design
Date Wed, 13 Feb 2002 14:14:15 GMT
rage on! I want java to survive .net.
If people use too much technology or over eloborate designs, their systems get
expensive to write & hard to maintain & then it looks like java is not good.
When I see the posts by people using frames I am pleased I avoid them.
One of my aims is to write systems that a beginner can read & a junior can
maintain.

As for EJB's - oops I may start to rant!
I write a business logic class to a standard design pattern, it can be called
from a Swing app or a struts Action.
If I want to call it from a remote server or it needs to participate in a
distributed transaction it should take only a few hours to write
a wrapper around it to make it an EJB session bean. It needs to receive/return
it's parameters as value objects (to save repeated calls acoss the network).
But like 98% of systems I have no such requirement - so no EJB's - for now.
So what's the big deal about them - can't most of us can remain blissfully
ignorant of them? 

Personally I'd like to see that b^%&$ PetStore written in 3 ways - 
1 - As a pet store would actually want it (Small scale architecture)
2 - Mid scale
3 - Monster scale.
And if we are really lucky No 1 write run nearly as fast as the .net version!!

--- stf <s.frank@vierundsechzig.de> wrote:
> 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" <keithbaconstruts@yahoo.com>
> To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
> 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 <s.frank@vierundsechzig.de> 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: <Mark_Glatzer@Instinet.com>
> > > To: <struts-user@jakarta.apache.org>
> > > 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:struts-user-unsubscribe@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <mailto:struts-user-help@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Send FREE Valentine eCards with Yahoo! Greetings!
> > http://greetings.yahoo.com
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
> >
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>
> 


__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com

--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message