I've more or less developed a "framework" for apps like this. It's nothing really official, but it's a common structure they all kind of follow. This represents what I'd call a "soft" framework, but I don't think it's appropriate for many situations anyway. So, I'd say unless you want to be building everything from scratch, Martin's references are probably the way to go.
If you do decide to go that route, I would be more than happy to share whatever experience I have to offer.
Before I forget, about the whole JS-to-Java object conversion thing I was toying with... it seems people on the list were pointing out some projects that do this already, and since I couldn't think of any real value-add (aside maybe from simplicity), I decided to not put much time into that. I did get it part-way (I was able to generate JS from a Java object, with some limitations), but I pretty much stopped there. I don't see the point in doing what has been done already unless I have something significant to add.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Martin Cooper wrote:
We are currently using two different frameworks (together). One is commercial - Isomorphic SmartClient - and one is open source - nWidgets.
SmartClient has a highly sophisticated widget set, and runs on just about every browser since Netscape 4.5. They essentially built an API layer on top of the browsers, and wrote everything else on top of that. Some of their widgets would take huge amounts of work to replicate, which is why we use them. ;-) We also use some server-side optimisation stuff that comes with SmartClient, and that helped hugely with our performance optimisations.
nWidgets is a much smaller, leaner framework that works on top of / along side the browser DOM. As such, it doesn't support older browsers. The widget set is mediocre, but the underpinnings are very powerful, and it's those underpinnings that we use it for. For example, it has some really nice mechanisms for partial page refresh that we use extensively.
One thing to bear in mind is that SmartClient is huge. They used to package it as a single 600KB .js file, which obviously has serious startup costs. We are now using a broken down version, where we can load only what we need on a give page, but I'm not sure if that made it into their product, or is custom for us. (We are probably their biggest customer.) nWidgets is much, much smaller.
There are other frameworks out there too. The one to watch is Dojo. This is being put together by the brains of all of the high quality open source frameworks, with the goal of pooling all of their knowledge and coming up with the ultimate in client side frameworks. These are a bunch of very smart people. (I know because two of them work for us. ;) However, their goals are lofty, and I'm not sure when Dojo will be ready for prime time. Other frameworks that I'm aware of, but have not used, are Burst and f(m), both of which are open source, and FacesClient Components (nee Odyssey Browser Framework) from IBM.
Some links:
http://www.isomorphic.com/index.jsp http://nwidgets.org/ http://www.dojotoolkit.org/ http://www-106.ibm.com/developerworks/websphere/library/techarticles/0411_hasson/0411_hasson.html
Hope this helps.
-- Martin Cooper
On Wed, 01 Dec 2004 12:27:48 -0500, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
Martin and Frank,
What resources are available for doing the sort of applications that you're talking about here?
Are there any frameworks or books out there that deal with these kinds of approaches? Or is all of this stuff only available in custom apps?
I didn't want to post this to struts-dev since, as was stated below, it's "way off topic"
My next project is going to involve porting a mainframe GUI customer information system to j2ee application servers, and I don't want to have to reinvent the wheel.
Thanks for any pointers you can provide (even google search terms would be appreciated).
-Mike
Martin Cooper <[EMAIL PROTECTED]> wrote:
On Sat, 30 Oct 2004 14:33:12 -0400, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
Martin Cooper wrote:
The app you describe does sound a little more extreme than one might want, but I think it's a great illustration of what can be done with JavaScript on the client. The primary app I work on in my day job also uses huge amounts of client side JavaScript to give the user a near-desktop experience. It enables us to provide functionality that just isn't possible with a server side rendering model. Our early attempts at this resulted in pretty horrible performance because of the amount of JavaScript we were downloading, but now that we've tuned things up (caching, compressing, minimizing downloads, etc.), performance is pretty awesome, and orders of magnitude better than where we started.
Sounds like we are very much in the same boat! I agree, the app I was referring to IS extreme... I wouldn't do an app to that degree again, but it was pretty much forced on me because of the IWT component which I had no choice but to use. I didn't have much choice but to do it this
way.
The two major apps I've architected (and mostly coded) subsequent to that one are not as extreme as that, but I still use a rather large amount of client-side scripting and DOM manipulation. Things like sorting of tables, very cool-looking "please wait" screens, popup calendars, tailoring of the interface based on user actions, and so on, things that as you said just isn't possible with a server side rendering model.
You'd probably enjoy seeing some of the stuff we have. Things like drag and drop, turning a column into a row and vice versa, hiding and showing rows and columns, virtual lists and trees, wizards, etc., all client side.
One of the primary "tricks" I learned with that first app that I've used over and over is first of all, frames are your friend, and second of all, hidden frames that store things are even MORE your friend. People that hate frames I think are afraid of them. It's true that there is some added complexity inherent with them, but it tends to be well worth it because you get better functionality possible and improved performance. Just that fact that you don't have to render the entire UI with every request makes it worth it.
Hidden (i)frames can definitely be a big help, but we've found that it's best to minimize the actual number of them, because (depending on the browser) they can chew up a lot of resources. Instead, we have most of our client-server communication go through one or two hidden iframes. We also prioritise multiple requests back to the server so that we can take maximum advantage of the default two connections that the browser will open simultaneously. Regular frames we don't use at all - we do that with div elements instead.
But we're definitely way off topic now... ;-)
-- Martin Cooper
A prime example in my most recent app is that a user can switch between a number of different clients on-the-fly. When the user first logs on, I download into a hidden frame all the pertinent details for all the clients and cache them there. It's purely read-only data, so no problem. When the user switches clients, I already have everything I need, so there's no need to call the server to get all that information and make the changes to the interface that are appropriate. Hence, performance as perceived by the user (and in truth there's not much besides what the user perceives that really matters when it comes to performance) is improved over what would otherwise be.
Another cool trick that I actually think I might have been the first person to pull off, is a Windows-like dropdown menu across the top that actually works across frames. The menu bar itself is a frame, and then there's the main portion of the screen below it, which is the only part of the UI the server ever renders, the menus are the same once they are loaded initially. However, when you click a top-level menu, the drop-down appears in the main frame. You can do all the Windows-like things with menus, like disabling and enabling (without server interaction), you get accelerator keys, icons, etc. None of this is unique any more, but I may have been the first to pull it off (if only I had published! :) ).
Actually, I don't think this is off-topic at all, given the Shale discussions. I think more people on this list need to be enlightened as to the possibilities of not tying the presentation layer to the server. In particular, I think we need to give careful consideration to the JSF issue, since that framework seems particularly unfriendly to the partial page rendering model.
Well, I think it may have been off-topic with regard to my proposal, but I absolutely couldn't agree more... Web developers in general I think need to get away from this idea of "the server should do everything". The server should do MOST things, but you simply can't get a truly rich, high-performance UI with the server-only mindset. At least that's what I believe, based on my experience.
To my knowledge, anyway, JSF is page oriented, relies on a page's component tree for rendering / processing, and does not provide for a client-side component to communicate back to its server-side partner without serialising and deserialising the page tree along with it. That pretty much breaks the partial page rendering scheme right there, unless you have the client and server parts of your components communicate with each other "out of band" as it were, which kinda defeats the purpose of having a component based framework.
I haven't looked at JSF much... I had an introduction to it at a JUG recently, and I wasn't overly impressed with what I saw. It seemed like an overly complex approach to things that are fairly well-understood (and not very complicated) now. There is a natural tendency of development to get more complex as time goes by it seems, but the ironic part is that it happens as a result of people coming up with things that they claim make things simpler and easier! If I have to go and write 10 different XML config files rather than some relatively simple HTML and Javascript, I don't so much care if my IDE can spit out those files for me or if I can make changes on-the-fly without touching actual code. At some point those config files might as well BE code because it's just about as complex, and people that rely on IDEs and tools to generate code for them are asking for trouble IMHO, most especially when that's ALL they know how to do. JSF struck me as just such a thing, at least from the admittedly quick glance I had of it.
But now I really AM getting off-topic :)
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
-- Martin Cooper
--
Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Don Brown wrote:
I'm personally fond of vcXMLRPC - http://www.vcdn.org/Public/XMLRPC/
-
and have used it successfully in several projects, an ASP application and a Struts-based application. I've heard of others, but that one has been good to me as it works with IE 5.5+ and Mozilla 1.0+.
This also seems to be a good list of non XML-RPC remote scripting for Javascript: http://www.ashleyit.com/rs/main.htm
I've never understood why XML-RPC and remote scripting in general haven't been more prevelent in web applications. The main limitation is a semi-recent browser, but that shouldn't be an issue in most web applications, especially within intranets. The excellent performance and developmental simplicity make web applications viable for more complex tasks.
Don
On Sat, 30 Oct 2004 00:18:08 -0400, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
It sounds like what your saying is that such a beast already
exists...
I'm looking now at the XML-RPC site at http://ws.apache.org/xmlrpc/, specifically the link to Client Classes... Is this what your
referring
to? If so, I think this is dealing with writing a Java-based
client,
not Javascript objects. Assuming that's not it though, can you
point me
in the right direction? I'm most definitely interested!
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Don Brown wrote:
On Fri, 29 Oct 2004 23:52:49 -0400, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
Argh, posted to the wrong list!
Well, in all honesty, this isn't something that was initiated by
me,
I've never had a thought of passing objects back and forth, so I'm
not
sure I can give you a real, concrete use case that would explain
it. I
certainly hear what your saying about XML. I myself have done
that very
thing in place of something like this.
I think the point that makes this interesting is the idea of
objects
end-to-end. Think of it almost like RMI between a browser-based
client
and a Java-based back-end. As in RMI, an object gets "flattened"
into
some data representation, transmitted and reconstituted on the
receiving
end. But on both sides of the conversation you have an object.
If what your asking is why not just pass XML representing the data instead of a representation of an object, then I'd say because
then you
have to know about some intermediary interpretation of an object,
namely
XML. It would kind of be like saying that instead of using RMI,
why not
just serialize an object's data as XML and transmit that, then
parse it
on the other end... Certainly that's done every day, but RMI is I
think
more elegant in that your always dealing in objects, and
conversion for
the sake of transport is done transparently.
That is not necessarily true. If you use XML-RPC, specifically one
of
the several client-side Javascript libraries for XML-RPC, your application, both on the client and server side, never have to
touch
XML. The XML-RPC library automatically handles serialization/deserialization as does the server side XML-RPC
library
(Apache has a great one for this). I use XML-RPC in several applications for the specific reason that I never have to deal with XML, yet I get rich communication between my web application and server.
Don
I know what your saying about tying to Javascript, but I'm not
sure
there's too many client-side scripting languages to worry about.
I
mean, Javascript and VBScript are all I can think of, and although
it's
been a while since I worked with VBScript, I don't recall there
being an
object creation mechanism like in Javascript, so I'm not sure how
big
a concern it is. Certainly I think it's safe to say that
Javascript is
by far the most popular client-side scripting language, and
therefore a
solution that is going to cover 75% of applications is probably
useful.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Martin Cooper wrote:
Just curious, and I'm sure I'm missing something (which is why
I'm
asking!), but why would you want to do this when there are XML
based
solutions there for the using, free, and that don't tie you to JavaScript?
Thanks.
-- Martin Cooper
On Fri, 29 Oct 2004 22:31:32 -0400, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
On the later idea, I intend to put together a proof-of-concept
next week
when I get back to the office. I have some family engagements
this
weekend that will keep me from getting started, and on Tuesday I
take
the first exam for my SCEA (not to mention the election!), but I
have
some spare cycles at work currently so I should pretty much have
the
rest of the week to play.
I only mention this because while I obviously can't stop anyone
else
from beating me to the punch, I do intend to persue this, so if
you have
any other itches to scratch, go for them, leave this one for me
if you
would :)
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Craig McClanahan wrote:
On Fri, 29 Oct 2004 21:28:52 -0400, Ted Husted
<[EMAIL PROTECTED]>
wrote:
That sounds great to me, Don. :)
We already have Struts-Faces and Struts-Examples on the trunk.
We
might as well add Struts-BSF and Struts-Flow to the mix.
+1.
Struts-BSF and Struts-Flow are not part of the core, so they
would
be not affected by a 1.2.x branch.
-Ted.
Note that there have been two overlapping discussions about
scripting
on the lists today ... Don's stuff in Struts Flow uses a
modified
Rhino (with continutations) to do scripting on the *server*
side,
while the earlier conversation about serializing a JavaScript
object
and converting it is about scripting on the *client* side,
using a
serialized form of JavaScript objects to pass data back and
forth
through a hidden field.
Both ideas are quite cool.
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
