|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rafael Steil wrote:
JSP / TagLibs
Rafael
gkatz wrote:Hi
HIbernate will probably always allow more advanced stuff than JPA. This is because JPA is a standard.
but... you gain standard compliance, a well defined API, the ability to switch persistence providers (i use toplink essintials - its just one jar as oposed to hibernate jar hell) with zero effort and more.
personally, i think JPA is the best way to go if jforum3 development has not started or reached a critical mass.
thanks for your time.
lorban wrote:May I suggest to give up JSP/taglibs and use a more modern approach for the view ?
I'd recommend to go with a components-based framework instead, like this one: http://wicket.apache.org/
This will provide a much cleaner separation between the Java business logic and the HTML templates while giving you Ajax support nearly for free.
Just my 2 cents.
It'd be very risky risky to bet against JSP tags at this point. In both cases, you need to write more than standard HTML into your code. The great majority of presentation developers are satisfied that JSP tags do a good job at isolating them from the Java code. I know the goals of Wicket, but if you look at real usage (including the provided samples), the page coder is also waist-high in Java coding. I have coded tons of JSP pages without needing to study the backing beans or API spec. There are good reasons why the JSP paradigm has flourished for so long.
Nino Martinez wrote:
...
yes, coding in java requires java code knowledge.
JSP's are just not that easy to maintain(no refactoring support etc), and they are not object oriented...
What would you like to edit the most:...
This discussion is not about Java coding. Obviously you need Java knowledge to code Java. We're talking about presentation coding, which should not require Java knowledge for simple use cases (at least).
It's a poor comparison because it doesn't use a JSP tag at all. It uses a JSP scriptlet. Using scriptlets is definitely worse than Wicket by requiring the presentation designer to code Java.
I don't expect my preferences to matter much here anways.
The point of my post was that the longevity of Wicket and similar frameworks is very uncertain in comparison to JSP, which is know to satisfy standard web app use cases, and has significant long-term obligations by many huge IT companies.
Considering Wicket is very different from considering Spring, which now has longevity and wide-spread buy-in.
Nino Martinez wrote:
or wicket equal :
Much better example.
In your JSP example, I see that somebody who knows no Java at all can specify arbitrary criteria, and can figure out from this little snipped how to also make a page to list all of the Canadian customers. They can do all this by working with a single JSP file. They could also display a fancy, paged and dynamically sorted table of the output with the same amount of code using the Displaytag tag library. If the JSP coder was just told the Customer bean getter names, he has ultimate control over what and how to display customer data: all presentation work done entirely with the JSP page of the presentation layer.
Your Wicket example ignores the filtering work which must be implemented somewhere. If somebody had done the controller work for the JSP example as they would have to do for your Wicket example (the most laborious of serveral methods being to code a new getter), the JSP page would be simplified correspondingly. (Not that I recommend that. It's often best to let the JSP writer decide how and what to display, like in your example).
[originally posted on jforum.net by blaine]
In your JSP example, I see that somebody who knows no Java at all can specify arbitrary criteria, and can figure out from this little snipped how to also make a page to list all of the Canadian customers. They can do all this by working with a single JSP file. They could also display a fancy, paged and dynamically sorted table of the output with the same amount of code using the Displaytag tag library. If the JSP coder was just told the Customer bean getter names, he has ultimate control over what and how to display customer data: all presentation work done entirely with the JSP page of the presentation layer.
Your Wicket example ignores the filtering work which must be implemented somewhere.
If somebody had done the controller work for the JSP example as they would have to do for your Wicket example (the most laborious of serveral methods being to code a new getter), the JSP page would be simplified correspondingly. (Not that I recommend that. It's often best to let the JSP writer decide how and what to display, like in your example).
blaine wrote:Most of the better products that I work with use extension "html" for HTML files, not ".htm", esp. open-source (and unix-friendly) products. No big deal, but use of *.htm is an (admittedly very imperfect) tip-off that the product wasn't designed for portability. I have done no statistical survey, but if I'm right, standardizing before files are in place would be an easy way to improve the impression of JForum 3.
Brahim B. wrote:Ah the danger of over simplified examples.
...
Another silly thing I am reading is all the formalized separation of the page designer from the application developer.
Facts:
- Once the web mock up is done, a web designer is no longer needed
- The complexity of templating, understanding the use cases, web application flow, etc., most often require the UI developer to be an application developer
- It would be must faster for the application developer to code the view layer than to collaborate with someone who knows nothing of the application tier every single detail.
|
He repaced his skull with glass. So you can see his brain. Kinda like this tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
|
