JavaScript Server Pages 0.2beta released

Discussions

News: JavaScript Server Pages 0.2beta released

  1. JavaScript Server Pages 0.2beta released (43 messages)

    I'd like to announce the 0.2beta release of JavaScript Server Pages (JSSP). It's available on SourceForge (http://jssp.sourceforge.net). JSSP is based on Mozilla Rhino and requires a Java servlet container to run. It can be added to existing Java web projects; data can be shared via the session object. Java classes can be easily accessed from within JSSP code. JSSP contains a language extension called JSSQL that allows you to embed SQL statements directly in the code, for example: <% var stmt = connection.SELECT * FROM Employees WHERE Name = ?Name?; stmt.Name = "Jack"; var rset = stmt.run(); while (rset.next()) { // do something with the result } %> JSSP handles database connections automatically for you, so you don't need to worry about closing resources. Another feature of JSSP is Dervish, a library that greatly simplifies AJAX programming. You can define and publish objects on the server and then invoke server side functions in the browser's JavaScript code. It's the JavaScript equivalent of Remote Method Invocation. Data structures on the server and the client are identical, so you don't have to code across language boundaries. JSSP has internationalization and unit test support. While it is not exactly a framework it is a useful tool for simple web applications because database access and simple AJAX tasks are a breeze. JSSP's motto is "keeping simple things simple". If you give it a try I'd appreciate your feedback!

    Threaded Messages (43)

  2. Why?[ Go to top ]

    Javascript on the server? It reminds me of VBScript on ASP. O dear, why did you do it? And why the SQL extension?
  3. Why not?[ Go to top ]

    Hi Antonio, there are a number of reasons why I did it: a) because I like JavaScript, b) to show that it can be done, c) because it didn't exist, d) because somebody else might actually find it useful, e) because I like simplicity and JSSP is in many respects the simplest HTML generating backend I could think of. The same goes for the SQL extension. If I can reduce the coding of simple database requests from 20 lines with JDBC down to five I think that's a good thing. Of course I don't want to impose anything on you. Feel free to evaluate it, and if you don't like it or don't see the purpose that's ok. Regards, Leo
  4. Re: Why not?[ Go to top ]

    .. c) because it didn't exist,
    d) ..
    Oh, it did exist - http://docs.sun.com/source/816-5930-10/intro.htm#13144 I just hoped that it has died ;)
  5. Re: Re: Why not?[ Go to top ]

    Hi Konstantin, you're right - it did exist. Even MS had come up with JScript on the server years ago. Seems nobody used it, though. Maybe it's time to breathe new life into it ;-) Thanks for the link, btw. Unfortunately, as far as I can see, iplanet isn't free. Regards, Leo
  6. Also see Project Phobos[ Go to top ]

    https://phobos.dev.java.net/ Also a javascript-based serverside language - and phobos *is* free.
  7. Re: Also see Project Phobos[ Go to top ]

    @Joseph: thanks for the link! @Henri: I recommend that you calm down and read posts more closely.
  8. Re: Re: Why not?[ Go to top ]

    Actually, server side javascript was pretty popular (broadvision) circa 1999.
  9. Re: Re: Why not?[ Go to top ]

    +1
  10. Re: Why not?[ Go to top ]

    Resin also supports JavaScript as a scripting language for JSP pages.
  11. Re: Why?[ Go to top ]

    Why are some developers/tech companies bent on making the software developer space so darned complicated and chaotic. Think of the young developers coming up now, having no knowledge of why this is a bad idea and having to learn the hard way (i.e. - JavaScript on the back-end). We should be engaged in learning from past technology problems and inefficiencies and hence not make those mistakes again. Why do you think Microsoft stopped pushing ASP or JScript? I appreciate that this developer has the technical savvy to get this implemented (i.e. - JavaScript on the server side). It maybe like art to him more than anything else - but please don't go evangelizing this option as a good way to go for developers. Push JavaScript to stay client side. I have a friend who retrofitted Pascal to do the same thing (i.e. Pascal on the server side). He's having a hard time getting developers to catch on to the idea - www.irietools.com Good job though, but I don't see myself switching from using Java on the server side to JavaScript. I like the Google approach with GWT in allowing developers to program with one language for the browser and the server side (Java for now), but for some reason I can't see using JavaScript for the browser and server side.
  12. Re: Why?[ Go to top ]

    Hi Douglas, that's a very valid point you're making. I thought that someone would come up with objections like this. However, after many years of doing Java on the server I think that there should simpler solutions, and that's what JSSP is intended to be - not a cure-all but a small tool for simple jobs. Definitely not the solution for large enterprise applications (as the documentation says). I know that there are a few developers who might like it, and that's the intended audience, not the "young developers" (who are probably most likely to use RoR or something more modern than Java or JavaScript anyway). So I think that JSSP does have its space in the diverse ecosystem of programming tools. I'm sorry if that comes across as "evangelizing". You seem to be one of those who believe that it's "a bad idea" to use JavaScript on the server. So far I haven't heard any compelling argument why this should be so. I'm not trying to convince you that JSSP might be the right tool for you, but please clarify your reason why you think JavaScript on the back-end is "the hard way". Kind regards, Leo P.S. I think that Microsoft abandoned JScript on the server because it was Not Invented Here. There never was any whole-hearted attempt to push it, anyway. It's ASP that they developed into ASP.NET.
  13. It made the code messy.[ Go to top ]

    We spent a lot effort to design a clean solution, the solution is to seperate concerns. No matter big or smaller, all projects have the same or similar concerns. It is not a good way to embedded SQL into web presentation layer, it is a common sense. I hope nobody will try to do this things again. Thank you very much.
  14. It made the code messy.[ Go to top ]

    Leo, Your idea is very creative. But I would say it do more harm than good in this crowded framework space. Do you mind telling us what's your background? Thanks.
  15. Re: It made the code messy.[ Go to top ]

    Hi Yujun, if you have a look at the JSSP documentation you will see that you can factor code out into reusable library modules. This gives you lots of choices how to organize the code base, and you don't need to mix database access and HTML generation in JSSP. I wonder how you arrived at this opinion. So separation of concerns is not really an issue. Regards, Leo
  16. Re: It made the code messy.[ Go to top ]

    Leo, Sorry I didn't read your document. Your example in the post gave me that impression. I respect your passion to create a better framework, I do. But I guess you have a long way to sell you idea. Thanks for your reply.
  17. Re: Why?[ Go to top ]

    Let me take a shot. I've drew the short straw and am doing some JS stuff. JS doesn't have good refactoring support. Its ability to define, ie, attach any thing to anywhere is a mess. Its lack of typing or static checking of method signatures is a mess. Its week debug support is a mess. Its cross-browser weaknesses are well known and a mess. GWT, again IMO, is the best alternative for JS development. The language doesn't scale well to larger apps. The more your write, the worse it is. Got a var and want to see how it is defined? Good luck. Anything can be in it at anytime. I would argue that Java represents the simplest, most advanced cross-platform solution available today. The most modern tool support, library support, and framework support around. It can be as simple or as complex as necessary, but like any tool, only as good as its wielder. I eagerly anticipate the conclusion of my torture. :-)
  18. Re: Why?[ Go to top ]

    Hi Douglas,

    that's a very valid point you're making. I thought that someone would come up with objections like this.

    However, after many years of doing Java on the server I think that there should simpler solutions, and that's what JSSP is intended to be - not a cure-all but a small tool for simple jobs. Definitely not the solution for large enterprise applications (as the documentation says). I know that there are a few developers who might like it, and that's the intended audience, not the "young developers" (who are probably most likely to use RoR or something more modern than Java or JavaScript anyway). So I think that JSSP does have its space in the diverse ecosystem of programming tools. I'm sorry if that comes across as "evangelizing".

    You seem to be one of those who believe that it's "a bad idea" to use JavaScript on the server. So far I haven't heard any compelling argument why this should be so. I'm not trying to convince you that JSSP might be the right tool for you, but please clarify your reason why you think JavaScript on the back-end is "the hard way".

    Kind regards, Leo

    P.S. I think that Microsoft abandoned JScript on the server because it was Not Invented Here. There never was any whole-hearted attempt to push it, anyway. It's ASP that they developed into ASP.NET.
    There are many reasons why I consider JavaScript on the server side a bad idea, but I'll provide the following reasons: 1) The life cycle of software projects: Based on my many years of experience in software development, so called small applications typically have a nasty habit of growing up on you, and to the point where they can become critical to the organization that you had created them for - hence, I normally take precautions to use programming languages (Typically mature and structured languages) and technology tools that can handle these unplanned growth spurts. JavaScript does not fit this bill. 2) Separation of Concerns As was mentioned by and earlier commenter, separation of concerns is usually a good place to start for all applications of significance. The reasons for this are many, but ease of maintenance and extensibility of your applications are some of the main ones. JavaScript has a place in this space which is where I typically consider should reside on the client side because of its strong support in web browsers and the ease of deployment being web based. I really am not a big fan of languages that aren't strongly typed for which there are obvious reasons. 3) Power and Flexibility Other mature structured languages such as Java provide you with much more options for whatever size applications you would want to implement. Backed by extensive native and third party class libraries/APIs, and strong open frameworks, you will not have to think twice about deciding which language to use for the implementation of your applications, especially true on the server side. If you're a web page designer/developer developing sites that have a lot of fancy graphics and special effects that will require dynamic behavior for the occasional registration form,or user poll forms, for which a database will be required and nothing on the order of implementing some complex,multiple use case business process, then fine, Server Side JavaScript or any other scripting language for that fact will do the trick - but my experience with some web developers in this group is that they tend to want to push these scripting languages too far to realms where their use is not appropriate - I recently read an article about a popular Social Networking Site developed in PHP suffering from serious growing pains based on the technology they used for the implementation of the site. 2) Learning to Program Contrary to what many persons believe, I don't think JavaScript is any easier to use than any other language, especially those with similar syntax (e.g. c, c++, Java, etc). I hate to hear when persons use this phrase (i.e. "easier than ...") as this is usually said based on some personal bias. If this statement of JavaScript being easier to use than whatever, why the heck are computer science schools wasting student's time and money in teaching them to program in languages that aren't as easy to program with as JavaScript? When I decide learn about a particular technology, I invest my time and effort in doing so knowing that the investment of my time and energy will have strong returns because all the potential benefits will guarantee longevity and wide applicability in its use before I am forced to learn something else. I don't like learning about everything because it's what's hip or would be sexy to do because you can, especially if the area of use of those technologies doesn't seem appropriate.
  19. horses for courses[ Go to top ]

    +1 for JSSP' intention. -1 for publishing the article on tss [& feeding a flamewar]
  20. VBScript... the horror[ Go to top ]

    Oh man... the horror. I remember writing VBScript. I even had the O'Reilly book. But, as he said... it might be useful to someone.
  21. do we have any translation phase as we have in the case of JSP to servlet and how exaclty a web container or appserver supports the extension .jssp Ananthu
  22. Hi Ananthu, there is a translation phase called "assembly". Code from .jssp files is assembled into intermediate files whose content is wrapped into JavaScript functions. The JSSPServlet executes these functions when a request for a .jssp page arrives. To integrate JSSP you configure the web.xml file to run the JSSPServlet for the *.jssp pattern. This means that you can integrate JSSP with existing Java web applications. You can share data via the session and use all available Java classes from JavaScript code. An important advantage - for me at least - is that JSSP preserves the line numbers in case of errors. Not doing so has always annoyed me with JSPs. Regards, Leo
  23. In the plethora of scripting languages and the Java 1.6 push for scripting extentions, one thing always annoyed me; Javascript, despite it's total domination of the Browser client, is almost non-existant on the server, and there is no file IO. JSSP is to be commended as both an intermediate solution to that problem, and a simple and creative tool of significant usability, without unneeded complexity, and leveraging the knowledge base of the average Java programmer. Surely it must be superior to the non-sense that is JSP, even though it merely extends it? Unfortunately, Leo, your simplicity and brilliance are totally lost on the average "Java jerk", as I like to refer to Java programmers these days. If they can understand it, if it actually does anything, and it doesn't provide a 1000 line stack trace, well then it just ain't J2EE.
  24. Re: Sounds like a winner to me..[ Go to top ]

    Stephen, thanks for your appreciation! I totally agree: JSSP is not at all "enterpricey", so this forum is perhaps the wrong audience. Anyway, the moderators accepted my post, so it can't be all wrong here. I wouldn't say that JSSP merely extends JSP, though. While its principal page serving mechanism is similar it supports library modules, unit testing, common code sections (browser/server), and there will be more features to come. Maybe the people here will find it more acceptable some day. Regards, Leo
  25. Re: Sounds like a winner to me..[ Go to top ]

    I don't think it has anything to do with being "enterprisey." I think people here question the use of javascript outside the browser. I certainly do. You stated that people didn't give you any reasons. A couple of people tried to. There is a simple question that one need ask one's self. Would they bet their job on this solution? I have bet my job on Struts, Spring, Hibernate, GWT, OSCache, Velocity, Quartz, Idea, etc.. I would not bet my job on a solution that involves running JS on the server.
  26. Re: Sounds like a winner to me..[ Go to top ]

    David: I understand your point of view, but I think you overestimate the gravity of the matter. JSSP is not something somebody will ever bet his job on. It's a simple solution to a simple problem: query databases and generate HTML. Add some i18n and be finished. That's all. If you want, use Java for the hard stuff. I do not at all question Struts and the other frameworks. I've been working with them long enough to understand their benefits and their shortcomings. JSSP is an attempt to go back to the basics, in what I think is the simplest way: a scripting language leveraging the power of Java on the JVM. And while I think that some of the reasons you mentioned do not convince me any more I see no point in getting into a language war. I also like strong, static typing but in some cases I just don't need it; I also prefer tool support for my language of choice but in some cases I can dispense with it; I don't think productivity depends on the language you use; I do believe that you can produce BS with any tool they give you - I've seen it more often than not; and I do believe that the scalability of an application depends on the designers and programmers behind it and that the actual programming language is just a detail. For me, programming is working around the shortcomings in your language. You see, this boils down to a matter of personal beliefs and opinions. Definitively not hard facts, which should be the basis of a sound discussion. So, if you don't ever use JSSP, that's fine. But please don't dismiss it on the general idea that "JavaScript outside the browser is bad". That just doesn't seem right. Regards, Leo
  27. Re: Sounds like a winner to me..[ Go to top ]

    Leo, I don't believe I've said anything about your implementation. I've spoken of JS, where I think it fails, and where I think it belongs. Your implementation may well be elegant, but,frankly, my question about betting your job, I think is not an overestimation, at least based on what I see here. Let's replace TSS "enterprisey" with the notion that most of use on this site, consider technologies posted here for our jobs, how we making our living as opposed to mere dalliance. If this is the case, every tech here has to be given that context. You tell me. Where should I use JSSP? If work, then I stand by my statement. In addition, I really don't understand how you can say that productivity doesn't depend on the language. Some items are simply faster(and easier) to implement in some languages than others. That's the point of different languages. If there were no productivity benefits, why not all use one language? The scalability that I was refering to was simply application performance, but one of code itself. Back in the days of K&R C, you didn't have to match function calls to function signatures during compile time. This was not considered a good thing. JS harkens back to those times and if that doesn't bother you, then you are a good deal more patient than I am. I personally don't consider the ability to add attributes(that may well be functions) on the fly to an existing object an advantage. It is a hassle because it is harder to understand what the code is doing at any given moment. Solving the problem is hard enough without that extra seasoning, IMO. All that being said, I respect the fact that you threw it out here. It's tough and I certainly wish you luck. Besides, who knows? I've been wrong plenty of times. Years ago I said "Who'd want to get DVDs through the mail?" Today, I'm all over Netflix.
  28. Re: Sounds like a winner to me..[ Go to top ]

    Hi David, JSSP is intended for deliberately kept small web projects. I intend to use it e.g. for an inventory of electronics parts. Another example would be a small time tracking system or something like Doodle for which I'd consider a full-blown Struts/Hibernate application to be overkill. The typical JSSP project would be a small, well-defined application consisting of a few web pages connected through a simple workflow, with a small database in the backend. I think it's perfectly acceptable to use a scripting language in such a setting, with the option to switch to Java at any point should the system get more complex. Another use would be, as a commenter said already, for generating the view parts of Java MVC applications. I think JSSP can speed up development a lot here because you don't have a build/deploy cycle for internationalized message resources and the amount of code can significantly reduced. Performance of JSSP is actually quite good as all JS code is internally compiled to Java byte code that can be JIT-optimized. I didn't notice any significant differences to JSPs, at least with the relatively simple test pages I use so far. True, the database access features add a little overhead but I think the ease of use amply makes up for that. And again, for high performance you can easily use Java classes to do the grunt work. As far as application scalability is concerned: As JSSP is based on Java and uses standard JDBC drivers and standard servlet containers I think it's fairly easy to scale horizontally by load-balancing the web servers or creating a database cluster. The technologies should be well-known and documented. That doesn't mean I advocate using JSSP for such applications, just that the possibility does exist (Henri, please note this). Having worked with JavaScript quite a bit I don't think that the ability to add dynamic attributes at runtime is a particularly dangerous development technique. After all, you don't go about and add all sorts of attributes randomly, just as you wouldn't use random interfaces and inheritance in Java. Typically you would follow a few patterns that are easy to recognize and document, so the program doesn't end up an unintelligible mess. Sure, programming in "dynamic" languages requires more discipline which Java programming somehow enforces "inherently", and it also requires some experience to avoid common pitfalls (just like any language does, btw). You mentioned that you like to work with GWT. IIRC the Java gets compiled to JS, lots of JS in fact. There are other JavaScript frameworks such as ext, qooxdoo, and more, which measure in KLOCs. These frameworks are well-documented, well-structured and offer an amazing set of features while still being maintainable and extendable. They clearly show that JavaScript is not a bad choice even for complex libraries. The point of productivity depending (or not) on language is very controversial, and the facts and opinions seem to vary greatly. What I mean to say is that I think that there are many factors that influence efficiency in software development, the actual programming language being just one of them. Personally I don't use JSSP at work. I have to use enterprise software of blood-curdling complexity, where even the act of adding three address lines to a web page was estimated to take three days (by a knowledgeable colleague). Generating HTML to print a simple customer order took ten days, eight of which were spent to work around various limitations in the framework. The whole application is huge, has about five abstraction layers and pretends to be MVC while mixing business logic, view and control logic everywhere. Unit testing is impossible due to the high ratio of interoperability with other systems; regression testing does not exist. Changes to one place may have random side effects as there is virtually no encapsulation and no layering in the code. Data is strewn all over the place in static fields of "API" classes and randomly accessed from everywhere. The programming language is statically typed but the manufacturer had it hacked up to be more "dynamic", the result being that you can put strings anywhere to get an error message in completely unrelated places when a type conversion fails. A customer order in the hierarchical object model, serialized to a simple text format, is about 600 kB in size (without any items). Add one item and the size goes up to 1.3 MB. Needless to say, the object model is completely undocumented, so it's guesswork where you have to read and store relevant values. The versioning system is next to unusable. The code is stored in a database, so you can't even grep through the source files, because there aren't any. This hideous code base practically violates all rules of sane software engineering. Yet it is sold at enormous cost, and consultants working in this field can earn more than two grand a day (not that I do, mind you, Henri). I don't complain, though. It pays the bills very nicely. It just occurs to me sometimes that there also should be simpler solutions. That's what JSSP is for ;-) Regards, Leo
  29. Re: Sounds like a winner to me..[ Go to top ]

    Sorry for not spacing the paragraphs. Too bad there isn't an edit button.
  30. Re: Sounds like a winner to me..[ Go to top ]

    Leo, From your code, <% var stmt = connection.SELECT * FROM Employees WHERE Name = ?Name?; stmt.Name = "Jack"; var rset = stmt.run(); while (rset.next()) { // do something with the result } %> It is not necessary to use JavaScript syntax, you can use Java syntax to do the same thing, <% Statement stmt = connection.prepateStatement("SELECT * FROM Employees WHERE Name = ?"); stmt.setString(1, "Jack"); ResultSet rset = stmt.execute(); while (rset.next()) { // do something with the result } %> You don't have to put extra statements and the result is pretty much similar. Why bother create another framework? The story in your post is common. But I really can't connect that to the necessity of a new framework. We already have millions AJAX frameworks to learn. :) By the age of 99, probably I can finish them. (Leo, this is not to you, but to the people who created so many AJAX frameworks, also not to Echo, Click, GWT and DWR up to 10 other frameworks since I believe they are valuable.) Regards
  31. Re: Sounds like a winner to me..[ Go to top ]

    Hi Yujun, first of all, I'd like to ask you to rewrite your JDBC code with the proper try-finally handling and resource cleanup. Then, please imagine a big update statement with twenty question marks in it. Now, please insert a column and question mark at the second position and imagine the fun you have updating all the indexes. JSSP closes all resources automatically for you. Having what I call "named placeholders" is not only a convenience but also makes the code easier to read and more robust and maintainable, simply by reducing the possibilities of making mistakes. Maybe you can also imagine what intellisense-enabled editors could do if you make SQL statements first-class citizens instead of string resources. JSSP is not a framework. It's a simple tool for simple purposes, though of course one could build frameworks on top of it. As for the whys, I think I have already answered that before. I absolutely don't want to force you to learn another software that you think is unnecessary. It's ok if you don't see or don't need any of the features JSSP can offer. And I don't take any of this personal, of course. Regards, Leo P.S. Life-long learning is an advantage, though ;-)
  32. Re: Sounds like a winner to me..[ Go to top ]

    Leo, Thanks for your reply. I wouldn't write that code in any project, just an illustration. I prefer Tags Only in JSP. After so many year back and forth, I actually prefer Stored Procedure over ORM, but I don't know how many people will agree with me. I totally agree with you the importance of learning. I just feel overwelmed by so many frameworks. I am glad you don't take this personal, at least I express my opinion in a friendly way. Regards
  33. Re: Sounds like a winner to me..[ Go to top ]

    Leo, Did you read the post about Echo3 and Click? If people's responses to a framework or tool are the same to those ones, I would say it is a success. Regards.
  34. Re: Why?[ Go to top ]

    It's a funny world. People complain even to free things, and sometimes do it very impolitely. We have several toolkits and solutions for different layers. This one also can be a n+1. And using it, is optional. People mix SQL and everything in their PHP codes yet. The same people might find this easy, cleaner and useful for their smaller projects. Who tells people should learn for 4 years to be able to create a simple JSF, Struts etc web page?
  35. Re: Why?[ Go to top ]

    It's a funny world. People complain even to free things, and sometimes do it very impolitely.
    I don't think "complaining" is exactly correct word. Perhaps it would be more accurate to say "laugh at" or "despise". Everybody is allowed to spend their time in whatever way they see fit, and likewise everybody has the right to criticize those who decide to spend their time in ways that doa not significantly benefit others. Building niche frameworks is somewhat akin to closet homosexualism -- it may be satisfactory to the persons who are doing it, but it does not benefit the human race at large. /Henri Karapuu
  36. hmmm...Javascript...[ Go to top ]

    hmmm...Javascript... Ever see this one ? http://www.ajaxman.net/wp-content/uploads/2007/11/ecma-cloud.png Cheers Olivier
  37. So, can you use it to create Java Applets? /Henri Karapuu
  38. Creating Java applets[ Go to top ]

    Hi Henri, of course you could create Java applets on demand. JSSP can serve binary data and I can imagine that you could generate class files or applet jars on the fly and serve them to the browser, either by compiling generated source or assembling class file data directly. I'm not sure whether this is what you want, though. JSSP is rather intended for the simple stuff like querying databases and generating HTML. You might be better off by building the applets in the traditional way. Regards, Leo
  39. Re: Creating Java applets[ Go to top ]

    Hi Henri,
    of course you could create Java applets on demand. JSSP can serve binary data and I can imagine that you could generate class files or applet jars on the fly and serve them to the browser
    Thats fabulous! Using JavaScript in the server for creating Java Applets for the client is so purely concentrated wickedness that this is bound to become an eternal classic. No, more than that, a Cult! I can hardly wait for the first sales meeting where i can present my new uber architecture to the consultants of a prospective client. I'm sure they will be floored. /Henri Karapuu
  40. jaxer[ Go to top ]

    http://www.aptana.com/jaxer, is another interesting option, when speaking about server side javascript.
  41. Jssp for the view[ Go to top ]

    Imho JSSP would be excellent for view layer. At our company, different people work on the service layer and on the presentation layer (aka design). Our designers have closely to zero knowledge about Java, but they know JS. They are always a little afraid when I hand over a jsp for design with a whole lot of unnesessary code in it (like looping trough a list with an iterator and casting every element to our bean class). Using JS in the view would make the code on page (loops, property access, no casting, easy etc.) much smaller and more understandable for no Java developers. But I would never implement any business logic in js, nor put SQL queries in it. That would be indeed a bad idea.
  42. Re: Jssp for the view[ Go to top ]

    Imho JSSP would be excellent for view layer.
    At our company, different people work on the service layer and on the presentation layer (aka design). Our designers have closely to zero knowledge about Java, but they know JS.
    I could indeed see a use case there, but I still wonder whether it'll be a good idea. A typical page consists out of client side and server side elements. Javascript is typically used for the client side logic, whereas Java or taglibs are used for the server side (view) logic. If both of these parts were to be expressed in javascript, wouldn't non-programmers be easily confused about which parts of their javascript run server side and which parts run client side? I can easily imagine these designers trying to 'alert' a server side javascript variable on the browser and complaining that it doesn't work. A smart editor might compensate this a bit, e.g. rendering server side javascript in one color and client side javscript in another, but that's probably quite a lot of extra work.
  43. Re: Jssp for the view[ Go to top ]

    Hi Arjan, I see your point and, sure, it's easier to mix server and client code. OTOH, maybe it just takes getting used to it. The editor you mentioned is in planning; currently I'm editing JSSP pages using a JSP editor in Eclipse. Even though it shows errors in the server side JS the syntax highlighting is pretty good to tell the two apart. As far as non-programmers are concerned, well I guess they would probably be confused anyway ;-)
  44. Leo, I would like to give you a 'thumbs up'. I wish more programmers were like you. And btw, I believe there may be a market for your framework. JS is certainly easier to approach than java for certain people that are not your 'regular experienced java developer/architect with more than 8 years of experience in enterprise application development'. Razvan