aspose file tools*
The moose likes JForum and the fly likes JSP 2 / JSTL are still considered, but we need good arguments on that. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » JForum
Bookmark "JSP 2 / JSTL are still considered, but we need good arguments on that." Watch "JSP 2 / JSTL are still considered, but we need good arguments on that." New topic
Author

JSP 2 / JSTL are still considered, but we need good arguments on that.

Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
I guess I wasn't clear in my last post on this topic. It might have seemed like I advocated JSTL. JSTL actually the worst thing that happened to JSP tag extensions, because it made people miss the real benefits of using custom tags.

I might do an article on the design pattern I proposed (I've been thinking about writing it for years).

In any case, take a look here:

http://www.genericgifts.com/

This site's templates don't have a single line of java inside JSP, and no template engine. All made with custom tags, and the design can be changed completely without the designers having to know anything about the internal structure of the store, other than a list of tags they can use.


[originally posted on jforum.net by bcc]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
You think you can help us on this? I like Freemarker, but if custom tags have such a greater benefit over it, we may opt for this approach then.

Rafael
[originally posted on jforum.net by Rafael Steil]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
Well, I could donate some existing code I've been using and write some more. Once you get used to the design pattern, making new tags is really easy.

Basically, you just need a displayer tag for each entity in the system. After that, retriever tags are just what retrieves the data bound to request/retrieved from data source/obtained some other way, and then provides it to the child tags (which are displayers or matchers).
Matchers are simply if statement implementations that either iterate or don't iterate, and when they do iterate, they provide that data to their child tags, and so on.

There is simply no reason to call any methods from within the template as you asked in the other post.

The only limitation of such approach is with internal templates, like e-mail notifications. The forum app would have to actually do an http request to the template to read it. But I have a newsletter/autoresponder application that works with way, and it's been working fine for a couple of years. At least I didn't run into any problems.

BTW, did you see this or maybe it's already been fixed in the trunk?
http://www.jforum.net/posts/list/0/2974.page#13011

We could do a small test to see if we run into any problems with such approach, but I really can't imagine what a template engine can do that java itself can't.

As far as the templates go, instead of having something like this:



we would have something like this:


and no template engine in the middle.




[originally posted on jforum.net by bcc]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
bcc, I also do use JSP/JSTL for my web applications, and a BIG problem is when we need to decorate some strings.

a pretty simple example is to format double numbers. calling a fmt:format is just too big.

also, to create a new tag is really a mess: you need to extend a class, create a tag file and so on. a macro would be much better.

maybe the easier way it to create a static method somewhere and map it to jforum, this way we can call ${jforum:showURL(topic)}, which is the simple way to create an EL expression. The problem here is the procedural approach. It would be much more beautiful to use $topic?url as we could do in freemarker. and simplier.

Obviously it is good to use JSP JSTL for an enterprise reason.
[originally posted on jforum.net by Paulo Silveira]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
Actually, as I said before, I don't think JSTL is a good idea.
But I do think that creating custom tags is. And creating a class for each tag handler and adding a descriptor is a small price to pay for the flexibility such approach offers.

Here is a base displayer tag I'm using in my code base:


As you can see, it pretty much takes care of all the formatting I need to do.

So for example, if some object has a boolean field and I want it displayed as Yes/No, then I would have something like this:

<mylib:SomeEntityDisplayer field="somefield" trueSubstitude="Yes" falseSubstitude="No"/>

And if I need it displayed as True/False for the same object at some other part of the template, I would simply use this:

<mylib:SomeEntityDisplayer field="somefield" trueSubstitude="True" falseSubstitude="False"/>

The same goes for numbers or any other data type.

Here is an actual tag from one template:

$<store:ProductDisplayer field="price" numberFormat="#.00"/>

If I need some zeroes padded, then I would change it to

$<store:ProductDisplayer field="price" numberFormat="#000.00"/>



[originally posted on jforum.net by bcc]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
I guess the point I'm trying to make is that V part of MVC is about making sure the designers don't need to call any methods or figure out how to do formatting or anything else for that matter.


[originally posted on jforum.net by bcc]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
I'm starting to like it.

How does loop / iterations look like? ( I mean, the tag java source).

Rafael
[originally posted on jforum.net by Rafael Steil]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
Here is an example of a tag that gets the shopping cart data from the parent tag (which in turn gets it from the session) and then iterates while providing child tags with a shopping cart item (one for each iteration).



Basically, the interface defines getShoppingCartItem() and the displayer tag that is placed inside doesn't need to know where that data comes from. It just calls getShoppingCartItem() of the parent.

For example, for that tag, the corresponding displayer is this:



As you can see, this displayer has a subtotal field that uses a float (I know, it's bad) but to illustrate a point about formatting. I can supply it with numerFormat attribute since the base displayer takes care of that.


So a simplified version of a template would look like this:

<store:ShoppingCartItemListForShoppingCartRetriever>
...this part loops...
$<store:ShoppingCartItemDisplayer field="subtotal" numberFormat="#0.00"/> ... and other tags
...this part loops...
</store:ShoppingCartItemListForShoppingCartRetriever>


The same thing with markers (if statements) those iterate only once or don't iterate at all.

Here is a shopping cart example from the site I mentioned.


<store:ShoppingCartInSessionStatusMatcher matchStatus="NONEMPTY">
<%@ include file="/cart_nonempty.inc" %>
</store:ShoppingCartInSessionStatusMatcher>

<store:ShoppingCartInSessionStatusMatcher matchStatus="EMPTY">
<%@ include file="/cart_empty.inc" %>
</store:ShoppingCartInSessionStatusMatcher>

The includes are simply to make managing the whole thing easier. I could've put the stuff right between the tags. In any case, only one of them iterates since the conditions are mutually exclusive.

To make it about a forum, a good example might be:

<UserInSession matchStatus="true">
<a href="/profile/<UserDisplayer field="user_id"/>.page">My Profile
</UserInSession>
<UserInSession matchStatus="false">
Log in
</UserInSession>


That's simplified, but the idea is that if a user is logged in, then the tag UserInSession also acts as a UserProvider (so that the user displayer inside can get fiels like user id or user name or any other field).

And the same user displayer tag can be used on the member list page, only inside a tag like UserListRetriever, which would also implement UserProvider.





[originally posted on jforum.net by bcc]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
Oh yeah, this part



Can be replaced by access to a data source. The idea is simple, in that point of the code, you can have access to all servlet api. So you can look at request parameters, session, application to figure out what you need to do. A topic id for a topic or a forum id from a request parameter, or a user in session, etc. After that, you can call the data access object to get the data you need from db/session/anywhere, and then store that data in a list in that object, and then iterate until you've looped through that list.


[originally posted on jforum.net by bcc]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
Here is a tag that gets an affiliate object from a data source based on aff.refnum request parameter and passes it to the children. This tag does not iterate more than once (that's just a specific thing). If it dealt with a list, it could iterate as well.


[originally posted on jforum.net by bcc]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
OK, I'm starting to like the idea of using taglibs. It is for sure harder than freemarker, but as there are a lot of libraries out there already, this counts a lot.

Also, I'm thinking that by supporting taglibs, the extensibility of JForum 3 will be enhanced.

Where can we find a good repository of tab libraries and / or information about that?

Rafael
[originally posted on jforum.net by Rafael Steil]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
There is not much to extend as it is the outer layer of the view component of the application.
The bulk of the work needed is to write tags for each entity or a business object that needs to be displayed and each iterator/matcher for the logic.

I can provide the base classes I'm using now. After that, it's somewhat repetitive, unless you want to generalize it and use a generic displayer that would use some sort of deployment descriptors for each entity. But because the structure of all tags is really simple, it's much easier to just pump out the classes for everything and anything.

Also, with internationalization, you would have something like:
<BlahBlahStatementDisplayer field="User.registerInformation"/>
for any statement in the template that is translated. The displayer would load from the same mechanism you are using now.

It's more work than with a template engine, but the templates themselves become real templates, not just skins.

For example, I needed to make my adsense block display on random to lower the banner blindness. I needed to simply show it half of the time a page is loaded. With the current engine, I couldn't find a way to do that within a template.

So I had to modify the PostAction and add

this.context.put("randomBinary", new Integer((Math.random()>0.5)?1:0));

in the list(), and then update the template with:

<#if randomBinary == 1>

adsense block here

</#if>

to post_show.htm.

Now, that really sucks. I needed something completely outside of the forum application logic, but I had to update the actual forum codebase.

Maybe there is a way to do that within the template engine by adding the methods that can be called somewhere in the descriptors and the calling them, but it still makes it hard to reparate stuff that's not directly in the forum from the forum application. And that would really be more difficult if one has to add something much more complex than a random number.


[originally posted on jforum.net by bcc]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
Just to chime in here. I would keep the existing template system. This JSP2 / JSTL just creates a hacked mess of code and template all combined. It gives you the power to make a mess. If people want new functions just add the function to the class. It's really simple to do. What would be nice is the ability to add plugins that add vars the the template calls. This when some one wanted to add some really alien part to a page. You make a plugin then call it from the template. BBC's point is correct it CAN be setup nicely, but it's SO TEMPTING to write hacks into the jsp pages that people do. The template system keeps a CLEAR delineation. People will bitch that they have to learn the Freemarker syntax, but I'm not sure that some one who can't take 10 minutes to figure out Freemarker should be modifying forums in the first place.

I expanded on this.
http://www.coderanch.com/t/576825
[originally posted on jforum.net by gwoodruf]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
My point is that there should not be a need to modify the business logic of the forum unless you are making changes to that logic.
If you only need to add some functionality that is not related to the forum logic (but needs to be on your pages), you should not have to deal with the forum code base at all. It should all end within the view.

It's a difference between a view and a skin. A view should be completely separate from everything else. A skin is just that. It lets you change some html and not much more.

As far as alowing to make a mess inside the templates, I don't belive that it's a prerogative of a software package to dictate what the end user should and should not be able to do.

I would even go further and say that creating a mechanism for plugins just to let the end user avoid having to modify the forum logic while changing a template is a hack, if anything is.



[originally posted on jforum.net by bcc]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
Also, I think you are missing the point about custom tags. It's not JSTL, and it's not about coding the logic within the template.
[originally posted on jforum.net by bcc]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
I'm thinking your point is that once it's all in taglibs you can mix and match across different sets? That JFoum becomes a set of standard tags you can call in from any page. That if you manage to plan it all out it can be very slick. But i's alot of taglib classes that are needed and a lot of complication. I prefer having the program in charge over the page.

How would you handle a feature where I could reskin the forums? E.G. Where you can take a template and modify it? Like where I can change a look and feel from a drop down box?
[originally posted on jforum.net by gwoodruf]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
Most of the tags would have similar code, so it's not as much coding as it seems. But creating tag handlers for all business objects is boring. But it only needs to be done once.

As far as changing the skin, you simply change the html in those templates as you would do with any other template setup.




[originally posted on jforum.net by bcc]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
Maybe I'm confused. Are you planning to jump the calls off real .jsp pages? Or calling into the jsp processor in some way?
[originally posted on jforum.net by gwoodruf]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
The tag handler classes would call the page(request) context to get the data, or a simpler/more flexible way is to have the tag handlers access model directly.

[originally posted on jforum.net by bcc]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
I agree on using JSP and taglibs.
[originally posted on jforum.net by lazee]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
Catching up on recent posts and should have put some of the stuff I posted here:

http://www.coderanch.com/t/576825 #13981

In this thread.

To add my two cents here. I think the recent discussion here is really about what technical level will be required to create a skin for Jforum 3.

On one hand, there is great developer "beauty" in business logic tags. As a developer my self, I can see that.

However, if your look at it from the point of view a person who "knows a lot about HTML, CSS" and want to make his/her forum look neat. A tag rich page can be a strange and unmodifiable mystery.

Is jForum 3 skinning going to be designed for developers or like phpBB, et.al for the power users?

That said, I know from doing several major apps who's look and feel is daily modified by non-techie "webmasters", it is possible to use JSP and Tags to find a happy medium.

FWIW, Some rules I go by are:

Little or no HTML should be generated by tags. GUI folks will always come up with better ways than I could ever think of to arrange things.

If I have to generate HTML, I work very hard to make sure that all GUI aspects of it are modifiable via documented CSS. E.g., no tables with cellspacing defined in the HTML that can only be changed in the code, etc.

Generated HTML should be highly modular. GUI folks will want to move / hide items. E.g., don't generate the entire "new post" form but figure out the best way to make it modular.

I try very hard to make the view JSPs display correctly in GUI design tools (e.g. DreamWeaver). This makes it quicker and easier for designers to make changes.

Keep JSP view pages limited to things like getting the data it needs from the controller (e.g. from the request, session, etc), using only as simple as possible if and loop logic, and <%= statements. <br />
If possible, I try to put all the non-display required logic above all the HTML. Generating clearly labeled variable that are used in the <%= statements. If the display logic requires a lot of code, it goes in a Bean or class. <br />
Anyway, those are the top of mind ones. None of them are hard and fast, just guidelines I try to balance between what the app needs from the developer side and what the GUI folks need. Take them or leave them.

The real point is jForum needs to consider what the end product is going to be and who it's going to serve.
[originally posted on jforum.net by monroe]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
Would it be possible to confine the jsp tag libs to a specific package and keep both system in place? The bang for the buck here is if you get people to merge jfoum tags with tags from other libraries. Seems to me you need to present a standard .jsp page to make that happen easily. It can be done with a mass of tag definition then some .jsp pages to kick them off right? Why not confine the jsp tags too a new package and make a new path for the jsp pages at least for the next version. Thus allow the user to choose the template system they want?

Another question is the performance hit for this setup, these jsp tags cause a lot of rattling between the jsp page and the tags, however the sections can be compiled right? So what is the performance impact of this?
[originally posted on jforum.net by gwoodruf]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
Little or no HTML should be generated by tags. GUI folks will always come up with better ways than I could ever think of to arrange things.


No HTML should be generated by tags. Absolutely no HTML. The job of a tag is to retrive data from controller(or directly from model) or iterate or display value(maybe formatted) of fields of business objects. That's all. Anything else, and you are hard-coding view into the tag handles. That's really bad.
There might be some cases where it's not possible to do otherwise, but it really should be avoided if at all possible.

Keep JSP view pages limited to things like getting the data it needs from the controller (e.g. from the request, session, etc), using only as simple as possible if and loop logic, and <%= statements.
<br />
Ideally, there shouldn't be any <%= %> in the template at all.

Instead of <%=myVariable%> which would simply mimic a template engine, you would have <mylib:MyObjectDisplayer filed="fieldName" format="formatting info" ...../>
There shouldn't be any java inside the jsp page, unless there is simply no other way to get things done.

The idea is that a template designer doesn't need to know anything about the internals of the forum except for the list of tags and what they do.

Where MyObjectDisplayer expects to get data from some parent tag that provides MyObject to its children. That parent tag would do the retrieval/iteration/conditional iteration, etc.

Would it be possible to confine the jsp tag libs to a specific package and keep both system in place?


You can have multiple taglibs on the same jsp page. They can't interoperate if they don't know what ther other lib does, but the basic iteration works as expected.



[originally posted on jforum.net by bcc]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
bcc wrote:
You can have multiple taglibs on the same jsp page. They can't interoperate if they don't know what ther other lib does, but the basic iteration works as expected.


No I mean can we leave the current skinning system as is. And build a jsptag layer as well as. Thus there would be two different 'Views' into the forums and the user could choose what they wanted the presentation layer to be?
[originally posted on jforum.net by gwoodruf]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
No I mean can we leave the current skinning system as is. And build a jsptag layer as well as. Thus there would be two different 'Views' into the forums and the user could choose what they wanted the presentation layer to be?


There is nothing stopping you from doing that. But why would you want to do two views? That's twice the coding and little benefit.
[originally posted on jforum.net by bcc]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
bcc wrote:
There is nothing stopping you from doing that. But why would you want to do two views? That's twice the coding and little benefit.


The current skin system is program directed you load a bunch of vars up and call the engine and it prints it out. The code is all java based and it's easy to understand and modify and very hard to get your self in trouble. Because the skin structure layer is so thin it's easy to see what goes where. This is best for the casual user.

The jsp model you promote is MUCH MORE powerful it's template directed. The template control gives you a bunch of tricks you are never going to get with skins. You can forge all sort of mash ups and have much more control. However there is a lot more work to adding things and the system is a LOT more opaque in terms of how stuff links up. The JSP tags makes many side effect calls setting this and that variable so later tags can pick it up. The linkage between tags can be very cryptic. However the complexity of all the linkage objects you DO get the ability to merge taglib - CRAZY powerful in terms of what you can do. For the power user absolutely best.

Realistically how many users will ever make use of the mashup? Or the ability to call in large optional processing blocks on custom pages? I'd say very few. 90% of people they install the forums and put a banner at the top. Lets give them the most simple model for making changes. It's already done and future features should only require simple template changes.

Since we can then layer the business objects on top we CAN also support the power users as well. If you were starting from scratch yes just pick one, but since the work on the skins is already complete I say just preserve it. It's a way to answer monroe's question about the target audience, make both user groups happy.



[originally posted on jforum.net by gwoodruf]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
^^^
I say stay freemarker.

You can create mashups via rest apis and feeds the forum provides.

Though stuff like this can help expose some of those apis.
http://struts.apache.org/2.x/docs/rest-plugin.html
[originally posted on jforum.net by sutter2k]
Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
We're using JSP 2.1

Rafael
[originally posted on jforum.net by Rafael Steil]
 
wood burning stoves
 
subject: JSP 2 / JSTL are still considered, but we need good arguments on that.
 
Similar Threads
HFS page 487, question 6
Custom Tags & JSP Standard Tag Library
Simple Tag - Sending/Setting an Attribute in the JSP
Failed SCWCD four times
describe about custom tags in jsp