This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes JForum and the fly likes [Architecture] Frameworks, tools, plugins and etc - What next Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Products » JForum
Bookmark "[Architecture] Frameworks, tools, plugins and etc - What next" Watch "[Architecture] Frameworks, tools, plugins and etc - What next" New topic
Author

[Architecture] Frameworks, tools, plugins and etc - What next

Migrated From Jforum.net
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
I'm creating this topic to discuss what we should to next, now that Guilherme has finished all Hibernate 3 code and its test cases. There are some things we have to define before continue working on JForum 3.

Please feel free to suggest and comment, always on a constructive fashion.

:arrow: Frameworks
  • VRaptor as controller. Really simple to use and very efficient.
  • Spring - Transaction manager (?), IoC and etc. We need people with expertise on this to help us know better where to effectively use Spring.
  • Hibernate for the Data Access Layer.
  • JPF - Java Plugin Framework as plugin engine. This is critical.
  • JSP / TagLibs
  • Lucene for search


  • :arrow: Plugins
    This is one of the major changes. Ideally, JForum should be completely pluggable and extensible through plugins. The motivation is that that way we can keep the core code focused on the very important stuff and make it possible to third party developers to easily extend JForum.

    So, for example, suppose your client asks you to put an Ad Manager in JForum. In the current 2.x version, you'll have to hack into JForum's core code, change HTML templates and still have to handle with Freemarker.

    Supporting plugins, the developer will be able to create a, say, "BannerPlugin" class, do it the way it wants and, without restarting JForum, load his new plugin and start using right away.

    :arrow: JSP and TagLibs
    Please note that it is taglibs, not JSTL. The topic http://www.coderanch.com/t/576678 gives a very good idea of what we want / need / will / how to do[/list]. By using JSP instead of Freemarker, we'll cut off the need of third parties to learn a new template engine and be able to count with the experience of anyone who already worked with TagLibs.

    :arrow: Tasks we have now
    So, given this brief introduction, we need to check on each point and find the best way to get it implemented.

    Tasks:

  • Spring - how to use it in JForum / how can it help JForum
  • Plugins / JPF - define the plugin architecture. A good start is to look at the demo application that comes with the library
  • VRaptor - how to organize it, when and how to use filters, where to put validations etc...
  • JSP / TagLibs - Check the topic http://www.coderanch.com/t/576678 for more information. Note that the taglib should never ever has a single line of HTML code.
  • Hibernate - Optimize the data model and the code. Not high priority currently.
  • Lucene - how to use it in a optimized fashion / what and how to index the content. Advanced search and etc...


  • Come on guys ;)

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

    Joined: Apr 22, 2012
    Posts: 17424
    Hello,

    some of this things are already implemented in JNuke as we talked in MSN and I believe that can be used in JForum. These are my toughts:

    :arrow: VRaptor:
    Does vRaptor has support for plugability? I meam, if we use JPF, is possible to easily update de url handlers in runtime?

    :arrow:JPF:
    I don't know much about JPF. When I was investigation for plugin support I figure out that it is pretty cool, but also complex. It's very similar to eclipse plugins, but I was looking for something simples.
    Then I realized that I could to that easily using Spring itself.
    Basically I've changed 3 things
    1. web.xml


    Note the classpath*:**/META-INF/*-module.xml. It is gonna look inside of the plugin jars and load the spring beasn in the file <foo>-module.xml.

    2. Obviously I have to release my jars with a folder named /META-INF/ with a Spring XML file.

    3. Some of the system's configuration are Sprign beans, like the menu itens. So, the menu itens are updated in runtime too.
    So, all configurations of the module that needs to be added in the system, needs to reside in a sprign bean.

    3. To change the Module Template Paths in the includes.


    That's all. The jars files can be uploaded/removed and the system context will be kept and the menu itens will be updates in the GUI.

    :arrow: JSP / TagLibs
    I prefer template engines. But, I will keep my eyes in this decission. This is important for me, because I would like to use the same view technology in JNuke, in order to make the both architectures similar to each other. Also, I'm very unhappy with the Velocity macros and I was planning to change to Freemarker. If JForum will use JSP, JNuke will probably use too.


    :arrow: Lucene for search
    I suggest you to take a look at LuceneInterceptor.
    https://jnuke.dev.java.net/source/browse/jnuke/jnuke/src/org/javanuke/core/indexer/LuceneInterceptor.java?rev=1.7&view=markup

    It is intercepting the crud methods of the Business Layer, and if the method is handling with a "Searchable" object then the indexes are updated.
    This way make my modules very pluggable. All that I need to do to index a new modules is to implements the Searchable interface and the method getDocument() in my Value Objects.
    Automatically this VO will be indexed.

    Regards,
    Franklin
    jnuke.com
    [originally posted on jforum.net by fsamir]
    Migrated From Jforum.net
    Ranch Hand

    Joined: Apr 22, 2012
    Posts: 17424
    Lucene sounds good, but besides multiple search indexes what else does it give? The search facilities in JForum 2.1.7 need dramatic improvement. When I search for a keyword in posts I'm given a list of topics! I don't want topics, I want the posts that the keyword appears in! I need the keyword(s) highlighted too (like on google search). The search index building seems to be in a state of disarray too, the quartz job scheduler for index rebuild seems weird. What would the Lucene multiple-indexes be used for anyways? Search on keyword in content, search by user, search by location (or other profile attribute)?

    Is there any code for 3.0 that compiles into a servlet with Lucene in it so I can see what is up?

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

    Joined: Apr 22, 2012
    Posts: 17424
    That's exactly what Lucene provides - a very decent and powerfull search engine.

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

    Joined: Apr 22, 2012
    Posts: 17424
    fsamir, do you already take a look at hibernate annotations lucene support?

    http://www.hibernate.org/hib_docs/annotations/reference/en/html_single/#lucene

    I think that is a better aproach. How about?

    And about the use of Spring for plugins, can you give us a more complete example?
    [originally posted on jforum.net by plentz]
    Migrated From Jforum.net
    Ranch Hand

    Joined: Apr 22, 2012
    Posts: 17424
    Franklin,

    in order to use Spring's plugin support, should all our components be tied to Spring? I mean, would it be necessary to build JForum as a "Spring application"?

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

    Joined: Apr 22, 2012
    Posts: 17424
    Hi Diego,

    Yes I did and I agree with you, it's probably a better approach.

    Rafael,

    I don't think so. I must "convert" your objects in Spring beans, only if you need to load them dynamically.

    For example, an puggable module has some Controllers and their respective URLs. To add a new Controler and it's URL handler, you need to make them as Spring Beans.
    But, you don't need to convert your infrastructure to be "Springable". For example, if one of your controllers inherits from jforum.AbstractController, this class doesn't needs to be a bean in Spring.

    That is a simple Spring file of JNuke(article-module.xml). I believe the file speaks for itself:




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

    Joined: Apr 22, 2012
    Posts: 17424
    i want to see lucene in the search engine and a improvement in the results navigation
    [originally posted on jforum.net by juancasi]
    Migrated From Jforum.net
    Ranch Hand

    Joined: Apr 22, 2012
    Posts: 17424
    I'd still like to see the ACEGI spring based security framework for authentication and authorization. Much better rememberme/SSO/filter chain support so you can implement redundant and fault tolerant security for accessing the forums. It is quite intuitive and has a lot of great features and extensibility.
    [originally posted on jforum.net by wajeremy]
    Migrated From Jforum.net
    Ranch Hand

    Joined: Apr 22, 2012
    Posts: 17424
    We are not going to use Struts.

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

    Joined: Apr 22, 2012
    Posts: 17424
    I wonder, nobody mentioned 'SiteMesh'.
    I think, sitemesh is becoming more popular compare all other templating technologies around.

    Even JIRA is using them.

    Another technology, is Spring MVC (instead of Struts)
    Obviously, you mayn't want to recode everything using new technology stack, but if you expermented with SpringMVC or SiteMesh, please let us know.

    3. In version 3.0, you are using struts classic or struts2?
    [originally posted on jforum.net by ajainy]
    Migrated From Jforum.net
    Ranch Hand

    Joined: Apr 22, 2012
    Posts: 17424
    Do you have an official date when the first JForum3 RC will be released?

    Thanks
    dev
    [originally posted on jforum.net by zr071207]
    Migrated From Jforum.net
    Ranch Hand

    Joined: Apr 22, 2012
    Posts: 17424
    How easy is it to expose JForum3 as a set of RESTful webservices with the outgoing representations of the resources as APP (Atom Publishing Protocol)?

    Thanks
    dev
    [originally posted on jforum.net by zr071207]
    Migrated From Jforum.net
    Ranch Hand

    Joined: Apr 22, 2012
    Posts: 17424
    I'm currently working full time to deliver version 2.1.8, so I can focus on JForum 3.

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

    Joined: Apr 22, 2012
    Posts: 17424
    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.
    [originally posted on jforum.net by lorban]
    Migrated From Jforum.net
    Ranch Hand

    Joined: Apr 22, 2012
    Posts: 17424
    Rafael Steil wrote:
  • JSP / TagLibs

  • Rafael


    Why JSP / TagLibs and not Freemarker / Taglibs?

    It seems that Freemarker supports custom taglibs, so you can get the benefits of a template engine and custom taglibs. And less changes to existing codings.

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

    Joined: Apr 22, 2012
    Posts: 17424
    We want to take advantage of the features of JSP 2.x.

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

    Joined: Apr 22, 2012
    Posts: 17424
    hi;
    i know you are going to use hibernate for jforum 3.
    have you considered using JPA (and hiebrnate as a persistance provider)?
    i have been using JPA for sometime now. its super easy, widelly adopted and probably the majority of developers will have a much easier time dealing with it instead of proprietry hibernate objects.
    what do you think?
    [originally posted on jforum.net by gkatz]
    Migrated From Jforum.net
    Ranch Hand

    Joined: Apr 22, 2012
    Posts: 17424
    Last time I checked there was some limitations with JPA. I will check again to see how's it going now.

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

    Joined: Apr 22, 2012
    Posts: 17424
    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.
    [originally posted on jforum.net by gkatz]
    Migrated From Jforum.net
    Ranch Hand

    Joined: Apr 22, 2012
    Posts: 17424
    Hi,

    I've developed a bridge that allows using JForum as portlet. The main problems were urls encoding, redirection, popup/iframe (connected user was lost in the popup/iframe), forbidden tag like <frame> and finally parsing urls. I've made some workaround (not easy :-) ) to deal with this:
    - add "porlet SSO" to allows popup and iframe
    - remove frame in admin mode
    - encode all urls
    - detect redirection
    - ...

    Another problem was about 'concept', for example, there is no login/logout or password management in a portlet. This is done by the portal.

    If we search 'portlet' in JForum, we find that many users are interested by JForum as portlet (Example: http://www.coderanch.com/t/575866 viewed 1969 times). It will be nice to think about JForum as a portlet for JForum3. Here is some suggestions:
    - add a property ?isportlet? in order to have same code for the servlet and portlet.
    - encode all urls
    - avoid "static" javascript redirection (document.location = '/contexPath/.../')
    - avoid frame: Portlet JSR168 generates only fragments of HTML for "body part" of the page. So, all tags like <html>, <head>, <frame>,... (tags that are not allowed as child of <body> ) are forbidden
    - avoid parsing urls: portlet can?t access to page url.

    For view engine, why don't use JSF? JSF was specified to allow implementations to support portlets.

    What do you think about all that?

    Regards,
    KT.

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

    Joined: Apr 22, 2012
    Posts: 17424
    JSF is way too complex.

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

    Joined: Apr 22, 2012
    Posts: 17424
    Hi,

    Why don't you envision the use of a Java Content Reporsitory such as Apache Jackrabbit (http://jackrabbit.apache.org/ )as your main underlying framework?

    Indeed a forum is basically a content tree. So the JSR170/283 (http://jcp.org/en/jsr/detail?id=283) were specifically designed for such applications. So you will avoid a lot of custom code as all your tree management, node properties, versioning support, multilanguage support, clustering compliance, caching system, etc... inlcuding all your persistance layers (you can map several Persistance Management Layer (PM) below Jackrabbit so anyone could then add his own PM according to his needs.

    Moreover Jackrabbit already fully integrates Lucene, POI and other PDFBox in order to index binary files. It also supports WebDAV so that anyone could read or post new threads through any DAV compliant client.

    Finally it would be really interesting for intranet (or even web site) usage when Jforum is coupled to another Portal Server, Web Content Management Server or other Document Management Server. Because, in a near future, all these applications will support the JCR at a certain level (level 1: in read-only mode or level 2 in read-write mode). So this means that an integrator could then easily share the same "Content Repository" for all these different apps, share the content (including binary files) between all these apps, etc... So it would definitvely avoid to to have one more legacy block with proprietary data that only JForum could read. From a user point of view, I think it would also be quite good to be able to access easily to his existing DMS server in order to choose a binary file (at the place or re-uploading it in Jforum) or for a Portal layer to make some "dashboard-like" portlet in order to populate a personalised home page (� la netvibes.com) with the last 5 Jforum entries or things like that.

    Some slides from David Nuescheler (lead architect for the JSR170/283) are quite interesting in order to see all the options already natively supported by a JCR. I think this is definitively worth a read (and perhaps also take a look to the spec) as the overlap with a disucssion forum is quite important at least form a back-end point of view.
    http://www.jahia.net/jahia/webdav/site/jahia_net/shared/Documentation/cmf-2006.pdf

    Applications such as the Chandlet Calendaring Server ( http://chandlerproject.org/bin/view/Projects/CosmoDevelopmentHome ) which is also basically a tree whose leafs are the "events" of a calendar based their initiative on top of Jackrabbit. So if they could map a calendar server on top of a JCR, I am we can do it for a discussion forum.

    My 2 cts,
    St�phane

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

    Joined: Apr 22, 2012
    Posts: 17424
    Rafael,

    here are my technology opinions:

    JSF:
    JSF in my opinion is a great Framework. I don't think it is too complex. Instead, I think it has a very clear design and especially for the Template/Gui designers, Java code is completely encapsulated so a webdesginer doesn't deal with java code in jsp pages.
    The powerful facelet framework allows to compose own components.
    Ajax in all components (and there are a lot) is one of the major goals for the future. JSF is an accepted standard.

    ACEGI:
    That would be great, especially if you want to integrate a CAS Server for SSO. You can secure Pages, Classes and Methods on a per Role-base. For me, Acegi (Spring-Security) is _the_ Java security framework you should take a look at.

    MDA:
    This is more a philolophical question on how to develop a complex spring/hibernate app.
    I had great success using a MDA approach to develop Java Web Applications. I used AndroMDA in many projects with great success. You don't have to deal writing own hibernate mapping files and documentation is done by design (so to say).
    The Hibernate Search API can be easily used. Also, Acegi Integration is very easy and can be modelled within the UML diagrams.
    Maybe worth looking at this technology.

    Struts:
    In my opinion a dead end.




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

    Joined: Apr 22, 2012
    Posts: 17424
    Hi,

    Recently, I've tested GWT and I found that it's really a good Ajax framework.

    If you have already developed with SWING, you'll appreciate GWT (It's same philosophy).

    Regards,
    KT (jforum_portlet bridge :-) ).
    [originally posted on jforum.net by ktlili]
    Migrated From Jforum.net
    Ranch Hand

    Joined: Apr 22, 2012
    Posts: 17424
    To be honest, I strongly like JSF too. It's not really complex, actually it makes web programming may more easily than it ever could be with standard JSP ways ...

    Simply using bindings ... lovely ...

    Been doing quite a big project with it too. The complex datatables and thus are being build within the beans and linked via component bindings to the jsf for instance ... works great .
    [originally posted on jforum.net by Sid]
    Migrated From Jforum.net
    Ranch Hand

    Joined: Apr 22, 2012
    Posts: 17424
    I love JSF too and have been working with it for quite some time now.
    I have a question though:
    instead of asking when will jforum 3 be ready i think i need to ask at what stage is it? it looks like the architecture and technologies are not done yet so jforum is not even in the preliminary development stages?
    so i guess jforum 3 is far far far away from being done.
    is this correct?
    thanks.
    [originally posted on jforum.net by gkatz]
    Migrated From Jforum.net
    Ranch Hand

    Joined: Apr 22, 2012
    Posts: 17424
    80% of the Hibernate code is done, as well the test cases for it. Freemarker templates still have to be coverted to JSP. Lucene code is OK as well, but other important pieces of the architecture, like the plugin system and exactly how Spring will be used, it's still open.

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

    Joined: Apr 22, 2012
    Posts: 17424
    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.


    Why not use JPA as the wrapper for domain classes and hibernate or toplink as provider? So +1 for JPA. There are several nice spring templates that goes hand in hand with JPA. Wicket is also very nice developing in, I cant do anything but recommend it!..

    regards
    [originally posted on jforum.net by Nino Martinez]
    Migrated From Jforum.net
    Ranch Hand

    Joined: Apr 22, 2012
    Posts: 17424
    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.
    [originally posted on jforum.net by blaine]
    Migrated From Jforum.net
    Ranch Hand

    Joined: Apr 22, 2012
    Posts: 17424

    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.



    yes, coding in java requires java code knowledge. However with the clear separation of java/html wicket provides it are indeed possible for a presentation developer to edit the markup, just leave the wicket:id's alone... Why JSP's have lived this long still puzzles me, probably legacy code for developers. 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:



    or

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

    Joined: Apr 22, 2012
    Posts: 17424
    It's hard to exaggerate how much it simplifies maintenance and upgrades if you make the delivered web app read-only. It also supports more deployment models (where app server does not explode the war file to disk, where the app files are distributed to cluster peers, etc.)

    Instead of having your app write files inside the exploded web app directory branch, you read customizations (like hibernate.cfg.xml, spring-app.xml) and write files under an external location. The external location can default to a directory like ${user.home}/jforum and this location can be changed in a portable way by a system property. I know that ${user.home} isn't always writable... that's what the system property is for.

    Container facilities like Tomcat's manager web app or WebSphere or WebLogic admin console can then be used to redeploy, without any risk to "data". For out-of-the-box users, upgrades can be performed without backup by just undeploying the old war and deploying the new war. For Java code customizers like myself, you can continually rebuild your war with ant and redeploy, without needing to back up and restore installation settings and runtime data.
    [originally posted on jforum.net by blaine]
    Migrated From Jforum.net
    Ranch Hand

    Joined: Apr 22, 2012
    Posts: 17424
    Nino Martinez wrote:
    ...

    yes, coding in java requires java code knowledge.


    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).


    JSP's are just not that easy to maintain(no refactoring support etc), and they are not object oriented...

    Well designed tag libraries like JSTL are object oriented. Check the JSTL library. Most of the tags encapsulate access to Java Beans.


    What would you like to edit the most:...


    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.
    [originally posted on jforum.net by blaine]
    Migrated From Jforum.net
    Ranch Hand

    Joined: Apr 22, 2012
    Posts: 17424

    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).

    True, editing presentation in wicket does not require any java knowledge what so ever... However it does in JSTL JSP or what ever framework that has a markup that contains logic(even rails has this)..


    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.

    True, that's right.. Then look at this(theres logic in JSTL in presentation layer):

    or wicket equal :


    I don't expect my preferences to matter much here anways.

    I believe that it's always interesting to hear others viewpoints.


    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.


    I consider JSP deprecated, and legacy. Having something thats mvc is good, and having something thats easly testable better.

    Considering Wicket is very different from considering Spring, which now has longevity and wide-spread buy-in.

    Wicket's been around since 2004 vs spring 2002... Wicket has higest mailing list rank on nabble(through put).. But I agree wicket is not that well spread yet.
    [originally posted on jforum.net by Nino Martinez]
    Migrated From Jforum.net
    Ranch Hand

    Joined: Apr 22, 2012
    Posts: 17424
    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]
    Migrated From Jforum.net
    Ranch Hand

    Joined: Apr 22, 2012
    Posts: 17424

    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.


    Hmm, so you say that it's better for the presentation designer to know some taglib script lang, but not java? Doesnt sound right to me. Better for the presentation designer to know nothing about the implementation(language) at all. I would'nt have these guys messing in my code...


    Your Wicket example ignores the filtering work which must be implemented somewhere.

    No it's not it's just implemented in the javaside of the page, where you can do it in sheer java or in the service layer etc.. That's the beauty of it all, a clear separation of markup and java.


    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).


    I see 3 roles doing web development, presentation css/html / presentation logic(the corrosponding java file in wicket), and the domain layer(which can include orm/etc). I dont see the presentation css/html messing with presentation logic, if they want something special the go ask the presentation logic developer... Now sometimes these roles are just one person...


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

    Joined: Apr 22, 2012
    Posts: 17424
    Most of the better products that I work with use extension "html" for HTML files, not ".htm", esp. open-source (and unix-friendly) products. .htm makes things smell like IIS. 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.

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

    Joined: Apr 22, 2012
    Posts: 17424
    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.


    Yup, that sounds right, wicket does this too. And im sure most of the frameworks out there does that too..
    [originally posted on jforum.net by Nino Martinez]
    Migrated From Jforum.net
    Ranch Hand

    Joined: Apr 22, 2012
    Posts: 17424
    Ah the danger of over simplified examples.

    Oh look! Just one line....

    What happened when you want to do more than that simplified example?

    JSP tags are the most powerful presentation widgets out there.
    I can create a custom tag that would turn a whole page into a single tag.
    Then I can turn and say: "oh, look... just one line".

    You do not need Java to use custom tags.
    The custom tag is just a another markup to learn.

    Whether you go Freemarker, Velocity templating, JSP, JSF, etc., there will be a learning curve for those web designers that don't know those technologies.

    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.


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

    Joined: Apr 22, 2012
    Posts: 17424
    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.



    I hope that the other participants don't assume that it's impossible to successfully separate page designer role from Java developer (both roles are development roles), just because some people have been unsuccessful at it. It entirely depends on the personnel skill sets and app, whether it makes sense to separate these roles. If the Java or DB team document their data objects properly, the tag libs are documented properly, and the Java team documents their Java beans properly, the roles can be separated. The ability to have this separation is a documented goal of the original J2EE specifications. It's pointless to argue against it since there are plenty of people (I work with several) whose job is web page development and who do not know Java. Another writer on this has opined that every capable Web front-end developer knows Java: There are plenty of bright, artistic, and capable people who do great front end work without knowing Java, using HTML, CSS, JavaScript, JSP. This setup won't work with Java developers who don't know how to document their work properly, or are too condescending to work alongside Gui developers who don't know Java..

    Regardless of people listing their opinions as "Facts", web designers' jobs do not end when mock-ups are finished, except for trivial apps. Ask any full-time, dedicated web page developer if all they do is create mock-ups.

    This setup is uncommon for small apps, but it is standard operating procedure at large companies with dedicated Gui developer personnel.
    [originally posted on jforum.net by blaine]
     
    It is sorta covered in the JavaRanch Style Guide.
     
    subject: [Architecture] Frameworks, tools, plugins and etc - What next
     
    Similar Threads
    Introducing JForum3
    Upgrading to RC4
    Upgrading to RC5
    JForum 2.1.8 relesead
    Introduction