Looking For Direction
in [Java Programming]
|
From: Alessio Stalla on 11 Jun 2010 08:16 On Jun 11, 12:20 pm, Arved Sandstrom <dces...(a)hotmail.com> wrote: > Alessio Stalla wrote: > > On Jun 11, 12:00 am, Arne Vajhøj <a...(a)vajhoej.dk> wrote: > >> On 10-06-2010 11:03, Alessio Stalla wrote: > > >>> On Jun 9, 11:19 pm, "JC"<jjcarde...(a)hotmail.com> wrote: > >>>> For the user interface I am thinking of something that is > >>>> integrated with a web browser. > >>> In addition to what everyone else said, I'd like to concentrate on > >>> this point. Are you really sure you need a web-based interface (i.e., > >>> do you really need to expose your application to potentially anyone > >>> anywhere), or are you considering it just because it's today's trend > >>> to build web applications? > >>> In my experience (2+ years in JSF + some minor projects with Struts) > >>> web applications often face an additional layer of complexity than > >>> client-server applications, and are generally limited in functionality > >>> (by the browser and by the stateless nature of the HTTP protocol). > >>> I think JSF especially is a very bad choice. I used the ICEFaces > >>> implementation, which adds its own host of problems, but JSF in > >>> general is terribly complex, and has a fundamentally bad design. > >>> Imagine someone proposed to you, for a client-server application: > >>> "hey, let's do this cool thing, let's keep *all* the GUI state on the > >>> server and ask for it *each and every time* the user interacts with > >>> the GUI"... you would say that's crazy, wouldn't you? Yet it's > >>> precisely what JSF does > >> That is what all non-AJAXified web apps does. > > > No. Most web frameworks reconstruct the page for every request, and, > > if applications are designed with a bit of cleverness, they only keep > > in session the minimum amount of state necessary to reconstruct the > > view. They don't keep in memory all the labels, all the CSS classes, > > all the component ids, ... like JSF does. > > That could conceivably become an issue if a _large_ number of > simultaneous (or near-simultaneous) requests caused a large number of > views to be rendered at the same time, sure. On under-performing > hardware and software, moreover. > > The scale of the JSF apps I work with is such that there are several > hundred users at any given time, requesting HTML/Javascript/CSS rendered > from fairly complex JSF, _and_ requesting new pages with rather high > frequency besides, and in all normal use that I can recall over the past > few years the servers don't even blink at this particular chore. > > The OP knows his own application best. But to me it doesn't sound like > the use of JSF is going to be a problem for him in this regard. I'm not making a point for efficiency (or lack thereof), but simply for the unneeded complexity of the approach. Have you ever tried to write custom components as composition of library components, for example? A thing that a component-based framework should support and even encourage, right? Yet it's painfully hard to do. > >> You can do AJAX with JSF if you want to. > > > You can, of course. I have only used ICEFaces which does a terrible > > job at it, but maybe other AJAX JSF implementations are saner. > > With all due respect it also depends on how you use ICEFaces. I've used > it a fair bit, and my rule of thumb is to use ICEFaces components only > when I actually need them. Which is not often. I don't use them for > every component on a page, for starters. Well, they explicitly don't encourage mixing ICE and non-ICE components on the page so we never did that. > To the degree that I have used ICEFaces I myself did _not_ have a > terrible experience. There, that's 2 opposing datapoints. > Sure, mine is just a data point. I'm trying to provide reasons for my negative opinion, but of course YMMV. > > >>> (and ICEFaces exacerbates the problem by > >>> forcing everything to be AJAX, even stuff that could be client-side > >>> only, like help tooltips). > >> AJAX is by definition running client side. > > > No, AJAX by definition is asking stuff to the server asynchronously. > > Why showing a help tooltip, or opening or closing a date selection > > popup, should ask the server for data? > > >>> Then, there's the complex and strict life > >>> cycle, > >> Just learn it. > > > I did learn it. I also endlessly fought against it when it proved to > > be too inflexible. How demented it is that to *empty* a form I have to > > generate an "immediate" event and cycle through the tree of components > > in the view to empty them *by hand*? And that I have to jump through > > hoops because "emptying" a component can mean different things for > > different components? > > Again with all due respect, it sounds to me like you were not working > with JSF - it sounds like you had expectations and pre-conceptions and > they didn't get met. I haven't used a single web framework in any > environment where I didn't have to adapt my thinking to it, rather than > the other way around. Every web framework has had blurbs and > documentation where they claim that they make it easy for the page > author and backing code implementor to write in a natural way - well, > take that with a pound of salt. I haven't used any where that's the > case, and I don't ever expect to. I don't expect the silver bullet that will easily solve all problems. However, I expect a framework to not make things harder than they normally are. > As for your stated use case, well, I haven't ever - not in several years > of intensively using JSF - ever cleared out a form the way you describe. > I've certainly read blog articles where people discuss doing it that > way, but I've never done it like that. Myself I simply blow away managed > beans if I have to. Blowing away managed beans is not enough to make components reload the value from the model if the clear action was immediate. And it has to be immediate if you want to skip validation, and you do want to skip it - preventing a form to be cleared because it has validation errors is silly, isn't it? So you have to .setValue(null) on all the components. Except that for some it's .setSubmittedValue(null) instead. And guess what, it's not documented anywhere and you have to discover it the hard way, by trial and error. And then, any events, not just form posts, go through the whole life cycle. You open the calendar popup of the date input component? The form gets validated. The value typed in an autocompleter changes... the form gets validated. Ugh. > >>> the macroscopic mistakes in the class hierarchy, > >> If we would ditch all API's where someone did not like something, > >> then there would not be many API's available. > > > Replicating isDisabled on all components rather than declaring it once > > on UIComponent and inheriting it is an objective mistake. And it's not > > just isDisabled, other methods are like that. You have to resort to > > reflection to do even simple things uniformly for all components. > > State saving is also cumbersome and error-prone, but I can live with > > that. Creating components programmatically is unnecessarily hard. > > Parsing dates by default forcing GMT timezone is wrong. Etc. etc. > > > Alessio > > I figure everyone's experience is different. I've certainly had issues > with JSF 1.x (and most if not all of them have gotten addressed with JSF > 2), but those issues don't exactly sound like yours. Generally speaking > I've found it fairly easy to get the pages I need with JSF, my own > Javascript, and CSS, and the right code in the backing beans, and the > pages I produce are handling some fairly complex busness situations. > > If I had any complaints about API shortcomings in J2EE then JSF wouldn't > be tops of the list. It might be #4 or #5 at most. For me it simply > doesn't cause many problems. Well, we didn't use J2EE APIs a lot; besides JSF 1.2, we only used some little JMS and JPA annotations. So, maybe JSF is not the worst part of J2EE; I sincerely hope it is, though ;) Alessio
From: David Kerber on 11 Jun 2010 08:28 In article <k2dQn.6548$z%6.2043(a)edtnps83>, dcest61(a)hotmail.com says... > > David Kerber wrote: > > In article <4c1033b3$0$278$14726298(a)news.sunsite.dk>, arne(a)vajhoej.dk > > says... > > > > ... > > > >> Given that he has Java, JDBC and Oracle experience then he should > >> have at least some advantages going Java instead of .NET. > > > > Not to mention that those are all cross-platform options. while .NET > > locks you into a windows-based network. > > The way Mono is moving along that's not strictly speaking true. In any > case, being "locked into" a Windows-based network is not exactly a > liability, not now and not for a few more decades. As it is, the > majority of fellow developers and clients that I deal with do J2SE/J2EE > on Windows. Every job I've had there's always been a fair bit - often a > majority - of other applications that have been on Windows. So it may be > a point of pride that your app in theory could run on many OS's, but > since almost everyone will have Windows who really cares? This is certainly true on the front (end-user) end, but much less so on the server side. Windows still makes up only a minority of the servers out there. D
From: Thomas Kellerer on 11 Jun 2010 08:37 Wanja Gayk, 11.06.2010 01:09: > Why would you want that? A proper Swing GUI gives you more freedom than > any browser based technology. If deployment is no problem, and with > Webstart it isn't, there is no point in using a web based GUI for a > system which is not intended to run on the web - and with webstart even > that would be no problem. WebStart combined with a decent module system like NetBeans or Eclipse offer (automatic download and installation of those modules) should take care of most of the deployment problems that have been around with older Client/Server technologies. Thomas
From: JC on 11 Jun 2010 12:45 > > To reiterate, I am _not_ suggesting that it's a trivial thing for a > _true_ DBA on RDBMS #1 to acquire the equivalent skills on RDBMS #2. > > AHS > I agree absolutely. My first exposure to one was in the late eighties with dBase III Plus on a stand-alone PC. That was actually when I first taught myself programming (with use of a ref manual of course); even before college. I later went on to R:Base; also on a stand-alone PC. Actually, everything I do on Oracle I learned on my own. And I think this was only possible due to a limited amount of formal training on Sybase and T/SQL. -JC
From: Lew on 11 Jun 2010 17:06
JC wrote: >>> 3. Interesting about the Vector class as I use java.util.Vector >>> extensively >>> in the app, schrieb Arne Vajhøj: >> You will just need to learn to type ArrayList instead. >> >> And you will probably not even notice any differences. Wanja Gayk wrote: > As long as he doesn't rely on synchronization. And if he does, then you have 'Collections.synchronizedList( List list )'. Provided that simple method-by-method synchronization is enough, which it often isn't. The advantage there for this and its sister methods is that the underlying 'List' can have properties appropriate to non-functional requirements without messing with the functional contract. This argues strongly in favor of your next point: > I'd also propose to use the interfaces Iterable, List or Collection as > much as possible to keep a maximum flexibiltyt o exchange the actual > implementation later. I call this style "type-based programming". You think algorithmically in terms of type interactions and express that using generics and interfaces, just plugging in implementation only when truly required, such as at initialization. It's sort of like declarative programming for algorithms, an oxymoron that is powerful in this case. -- Lew |