Discussions

News: TSS relaunches on Tapestry and JDO; Tapestry article posted

  1. TSS recently relaunched its back end infrastructure on Tapestry and JDO (SolarMetric Kodo), replacing an older home-grown servlet framework + BMP entity bean layer that was in place for nearly 5 years. These choices were not politically motivated, but based on our requirements and available resources.

    Tapestry founder Howard Lewis Ship implemented the Tapestry conversion and has written an article about it. You can read the article here:
    http://www.theserverside.com/articles/article.tss?l=TSSTapestry

    We chose Tapestry because:
    - Its component approach was well suited to TSS, which has many similar pages with minor differences
    - Simplicity of HTML templates well suited to editing by content editors
    - We had the #1 Tapestry Expert on hand :-)

    JDO thought SolarMetric Kodo was the right choice for us because:
    - It's a standard so we weren't locked in
    - It's a compelling solution to POJO persistence that is available now, not in 2006
    - It allowed us to be more flexible with our object model
    - Kodo itself has a lot of optimizations that fit in well with our cluster architecture (distributed query caches, etc)
    - Solid integration with Tangosol Coherence
    - Tools: Top class query browser. Tool that shows us performance hot points, etc

    The conversion of TheServerSide.com to Tapestry and JDO has been a success. Performance and stability are at least as good as the 1.0 version of the application (largely thanks to improved caching provided by the combination of SolarMetric Kodo JDO for database access, and Tangosol Coherence for cluster-wide caching). End users have barely noticed the changes, except in the form of user interface improvements.

    With this new infrastructure in place we will be in a position to more quickly evolve TSS and bring you new features. We thank our partners Howard Lewis Ship (Tapestry) and SolarMetric for all their help.

    Threaded Messages (166)

  2. Great work to Floyd and his Team!

    Still a question:
    How many persons/months do you need to update your system: presentation layer with Tapestry and business layer with JDO?

    Thanks a lot!
    Lofi.
  3. Great work to Floyd and his Team!Still a question:How many persons/months do you need to update your system: presentation layer with Tapestry and business layer with JDO? Thanks a lot!Lofi.

    I worked for a bit over three months at maybe 3/4 time. It would have been faster (if existing links were not so important) to have built a new site, with equivalent functionality, from scratch. TSS is a relatively simple site, but there are a number of nuances (rarely seen functionality) ... adding up to nearly 80 distinct pages.
  4. Additional note: prior to starting the work, I had zero exposure to the code, which is somewhat unusual for a conversion effort. So a lot of that time was ramp up time, learning the code, build process, etc.
  5. I can't remember what the error handling behavior of TSS was for mistyped links to article content before the transition, but the post-transition error handling behavior should probably behave like typing an invalid thread_id (ie-fail quietly and redirect you to the front page)

    http://www.theserverside.com/articles/article.tss?l=TSSSophistry
  6. Great work to Floyd and his Team!
    I actually didn't have much to do with it. Howard Lewis Ship and some former developers/trainers from The Middleware Company led the effort. However, I was part of the decision to use Tapestry/JDO and I'm very pleased with the results.
  7. It's notable the performance improvement.

    are you using jdo 2 features?
  8. Congratulations to all involved.
  9. Great Work !!![ Go to top ]

    Yet another site which is running successfully on Tapestry :)
  10. Re: Great Work !!![ Go to top ]

    Just forgot to ask if the TSS.NET is using the same technologies. As far as i have seen using the View Source Option in the browsers ;) it seems that both are backed by Tapestry, but an official statement will make the diffrence :).
  11. Re: Great Work !!![ Go to top ]

    I talked to one of the TSS guys at a conference he said that initially when TSS.net launched they felt they should eat their own dog food and have an implementation in dotnet. He said that eventually it got to be too much of a maintenance nightmare trying to keep both code bases up to date with the newest features of the site. Eventually they abandonded the dotnet version in favor of just maintaining one code base. Thats why the urls all ended in tss. So it wasn't that dotnet was bad and java was better just that they didn't want to develop everything twice.
  12. Re: Great Work !!![ Go to top ]

    Is that you Greg Leake?

    Tapestry is a good choice inmo, except Wicket is the new game in town.
  13. TSS relaunches on Tapestry[ Go to top ]

    Not going with the hyped JSF way huh??
    Interesting... ;-)

    And, why did you choose JDO over Hibernate? Standards? Support? Something else?
  14. TSS relaunches on Tapestry[ Go to top ]

    I am also keen to know why JDO was chosen as opposed to Hibernate.
  15. TSS relaunches on Tapestry[ Go to top ]

    And, why did you choose JDO over Hibernate? Standards? Support? Something else?

    One major reason I see - Kodo supports distributed query caching, but Hibernate can't.

    Maxim Kramarenko,
    TrackStudio - Hierarchical bug tracking software
  16. TSS relaunches on Tapestry[ Go to top ]

    [blockquote]One major reason I see - Kodo supports distributed query caching, but Hibernate can't. [/blockquote]

    Bzzzt. Wrong. Supported for more than a year, IIRC. Next try.
  17. TSS relaunches on Tapestry[ Go to top ]

    Supported for more than a year

    Glad to listen, will try. Thank you.
  18. nonsense[ Go to top ]

    And, why did you choose JDO over Hibernate? Standards? Support? Something else?
    One major reason I see - Kodo supports distributed query caching, but Hibernate can't. Maxim Kramarenko,TrackStudio - Hierarchical bug tracking software

    This is of course not correct, as simple perusal of our online documentation will show.

    http://www.hibernate.org/hib_docs/reference/en/html/performance.html#performance-cache

    We have several customers successfully using distributed query cache with Hibernate, along with many other users.
  19. nonsense[ Go to top ]

    http://www.hibernate.org/hib_docs/reference/en/html/performance.html#performance-cache

    We have several customers successfully using distributed query cache with Hibernate, along with many other users.

    It is my understanding that Hibernate also supports a number of other (commercial) vendor's cache implementations, such as one for Coherence (i.e. CoherenceCacheProvider), although I am wondering why these implementations are missing from the tables in the documentation that Gavin points to.

    Later,
    Rob Misek
    Tangosol, Inc.
  20. nonsense[ Go to top ]

    although I am wondering why these implementations are missing from the tables in the documentation that Gavin points to.

    Because its the reference documentation, not a complete market survey. It would also be nice if you could take the cache provider Gavin wrote for your product (for free, if I remember) and maintain it in your codebase instead of on our wiki. Thats why we have clear interfaces for extension points.
  21. caches[ Go to top ]

    http://www.hibernate.org/hib_docs/reference/en/html/performance.html#performance-cacheWe have several customers successfully using distributed query cache with Hibernate, along with many other users.
    It is my understanding that Hibernate also supports a number of other (commercial) vendor's cache implementations, such as one for Coherence (i.e. CoherenceCacheProvider), although I am wondering why these implementations are missing from the tables in the documentation that Gavin points to. Later,Rob MisekTangosol, Inc.

    Because Hibernate is LGPL, we can't ship code that depends upon commercial product specific APIs. It's also not right to have our reference documentation talk about features which are not available out of the box.

    It would be better if you guys provided an implementation of our SPI (which is trivial), with your product.
  22. caches[ Go to top ]

    Because Hibernate is LGPL, we can't ship code that depends upon commercial product specific APIs. It's also not right to have our reference documentation talk about features which are not available out of the box.It would be better if you guys provided an implementation of our SPI (which is trivial), with your product.

    Thanks for the clarification Gavin.

    Later,
    Rob Misek
    Tangosol, Inc.
    Coherence: It just works.
  23. A interesting article to read. But i'm a bit confused about the fact that when using jsp you get many same html blocks in your jsp pages, like described in "Converting JSPs to Tapestry pages". Doesn't jsp have something like macro's, like velocity, these one are quite handy. You define a macro "printBox(title, color)" and put all html for printing a box in the macro. Then when you want a box you call "printBox("title" "black").
  24. A interesting article to read. But i'm a bit confused about the fact that when using jsp you get many same html blocks in your jsp pages, like described in "Converting JSPs to Tapestry pages". Doesn't jsp have something like macro's, like velocity, these one are quite handy. You define a macro "printBox(title, color)" and put all html for printing a box in the macro. Then when you want a box you call "printBox("title" "black").

    JSP is catching up to where Tapestry was in 2000 (or, for that matter, where Velocity was at the same time); it is now more possible to create simple "macro-like" components in JSPs ... but that wasn't the technology when TSS 1.0 was created. We could have realized a small advantage by moving to JSP 2.0 technologies, but not on the same scale as what is possible with Tapestry.
  25. But again what are the advantages for HTML components described in your article over tag files (or custom tags) in JSP?

    Marina
    http://www.servletsuite.com
  26. But again what are the advantages for HTML components described in your article over tag files (or custom tags) in JSP?

    Tags, even with the JSP 2.0 improvements, are extremely cumbersome compared to Tapestry components, both in how you create and register the components, and how you reference them inside your pages (and other components). So, with sufficient torture of your code, you could accomplish similar things ... Tapestry just makes it natural and easy to hook everything together.

    At the core, its because Tapestry pages and components are stateful objects; normal Java objects with methods and properties. Combine that with OGNL (the Tapestry expression language) and you have a wide, natural, rich backbone for moving data around. By contrast, kludging data into and out of the HttpServletRequest or HttpSession seems convulted and anemic.

    There are a number of things that, with Tapestry's component object model, are possible in Tapestry that would be daunting, at the very least, using other technologies.

    For example; there are several different pages that allow you to post a new thread: one for each category (news, discussions, patterns, etc.).

    This is all accomplished with a single PostForm component that is parameterized to adapt to the different pages. This allows fields to be hidden or unhidden, and allows text and prompts to be customized. However, all the form submission logic is in exactly one place, complete with back end interaction and error recovery. This is a very real, very cool, very pragmatic adoption of the Don't Repeat Yourself principle.

    The ability to easily connect pages, components, and back end services together into a single, functional whole, is a hallmark of Tapestry (and Tapestry + HiveMind) development.

    Remember: it's a web application. Bytes come in and bytes go out ... its just a matter of how much pain is involved in getting the right bytes to go out that count. Short of opening up the source code, I'm not going to be able to show you just how much can be accomplished with so little.

    On the other hand, if you are really curious, there are many fine examples of Tapestry applications that are ready to be dissected and analyzed; including the Virtual Library (EJB and JDO versions), a couple of Pet stores, and so forth. Part of my book, Tapestry In Action, is a detailed examination of the EJB Virtual Library.

    I'll be expanding on this discussion at TheServerSide Symposium.
  27. For example; there are several different pages that allow you to post a new thread: one for each category (news, discussions, patterns, etc.). This is all accomplished with a single PostForm component that is parameterized to adapt to the different pages. This allows fields to be hidden or unhidden, and allows text and prompts to be customized. However, all the form submission logic is in exactly one place, complete with back end interaction and error recovery. This is a very real, very cool, very pragmatic adoption of the Don't Repeat Yourself principle.

    Really? Can you use that same class as the backing for a JAX/RPC request, SOAP document, email message, or JMS message? Just wondering, 'cause that's the kind of thing you get with a generic Command pattern framework...
  28. Really? Can you use that same class as the backing for a JAX/RPC request, SOAP document, email message, or JMS message? Just wondering, 'cause that's the kind of thing you get with a generic Command pattern framework...

    Presentation, error handling, etc. are all different with those three different presentation layers. If your presentation layer delegates to business logic (I favor using HiveMind and injecting business services into my pages) then you get proper reuse.
  29. Really? Can you use that same class as the backing for a JAX/RPC request, SOAP document, email message, or JMS message? Just wondering, 'cause that's the kind of thing you get with a generic Command pattern framework...
    Presentation, error handling, etc. are all different with those three different presentation layers. If your presentation layer delegates to business logic (I favor using HiveMind and injecting business services into my pages) then you get proper reuse.

    Yes, presentation is different, but that's why we separate our view from our controller and model. Conceptually they are all just request / response (optional response) patterns. Your Command objects (Actions) just get some data set on them from the request, do something with it, and then the framework runs some result (which could be rendering a web page, sending an email, broadcasting a message on a Topic, etc).

    I agree that reuse is important, but I like to reuse as much as possible, not just things named *Service.
  30. Yes, presentation is different, but that's why we separate our view from our controller and model. Conceptually they are all just request / response (optional response) patterns. Your Command objects (Actions) just get some data set on them from the request, do something with it, and then the framework runs some result (which could be rendering a web page, sending an email, broadcasting a message on a Topic, etc). I agree that reuse is important, but I like to reuse as much as possible, not just things named *Service.
    Whoa, as if I said it myself ;)
    Tapestry just makes it natural and easy to hook everything together. At the core, its because Tapestry pages and components are stateful objects;
    Why are the pages & components stateful? Isn't a page or component the 'View' in MVC pattern and the 'Model' holds the state.
    Totally agree, the view must be stateful, the model should hold the state.
    A typical servlet/struts approach involves storing temporary data as request or session attributes, a practice I call engineered coincidences.
    Storing some assorted values in the session is not nice, but storing current data that a client works with and which is not persisted yet, in the business class, is the proper and clean approach of separation of concerns. But I must shut up and try Tapestry before making judgements. Hopefully, a "Java class, which acts as the model" can be used for other views with little modifications.
  31. Tapestry just makes it natural and easy to hook everything together. At the core, its because Tapestry pages and components are stateful objects;
    Why are the pages & components stateful? Isn't a page or component the 'View' in MVC pattern and the 'Model' holds the state.
    Totally agree, the view must be stateful, the model should hold the state.
    A typical servlet/struts approach involves storing temporary data as request or session attributes, a practice I call engineered coincidences.
    Storing some assorted values in the session is not nice, but storing current data that a client works with and which is not persisted yet, in the business class, is the proper and clean approach of separation of concerns. But I must shut up and try Tapestry before making judgements. Hopefully, a "Java class, which acts as the model" can be used for other views with little modifications.

    Not sure all of this is correct but from what I understand: The data is stored in the session under the hood. Its just the way you program and access it that is different. Its accessed much as a JTextField value would be in Swing. There is one page object and one object for each component in the page. Before your code gets to process the request, these components are populated with the session specific data. Your code goes into some kind of event handler which manipulates the data. Then the framework takes over again and displays the next page reflecting the change in the underlying data. So Tapestry is a mapping between request/response oriented way of programming and propery/event oriented way of programming. But i'm not sure.
  32. Not sure all of this is correct but from what I understand: The data is stored in the session under the hood. Its just the way you program and access it that is different.

    Excerpt from the article:
    The existing (1.0) version of TheServerSide.com is entirely stateless – no HttpSession was allowed; the new version, 2.0, inherited this same requirement.
  33. Not sure all of this is correct but from what I understand: The data is stored in the session under the hood. Its just the way you program and access it that is different.
    Excerpt from the article:
    The existing (1.0) version of TheServerSide.com is entirely stateless – no HttpSession was allowed; the new version, 2.0, inherited this same requirement.

    Ok, so no persistent properties. The above applies with the components being populated from the request (as opposed from the session). If any of the properties needed to be persisted between requests, then they would be stored in the session.
  34. Not sure all of this is correct but from what I understand: The data is stored in the session under the hood. Its just the way you program and access it that is different. Its accessed much as a JTextField value would be in Swing. There is one page object and one object for each component in the page. Before your code gets to process the request, these components are populated with the session specific data. Your code goes into some kind of event handler which manipulates the data. Then the framework takes over again and displays the next page reflecting the change in the underlying data. So Tapestry is a mapping between request/response oriented way of programming and propery/event oriented way of programming. But i'm not sure.

    You're pretty much on the money; it's just that many properties are transient (used during a request, and not stored in the HttpSession) and there's still huge value in that data being in the form of properties. The fact that properties can be made to persist between requests (when HttpSession useage is allowable) is icing on the cake.
  35. Tapestry just makes it natural and easy to hook everything together. At the core, its because Tapestry pages and components are stateful objects;
    Why are the pages & components stateful? Isn't a page or component the 'View' in MVC pattern and the 'Model' holds the state.
    Totally agree, the view must NOT be stateful, the model should hold the state.
    A typical servlet/struts approach involves storing temporary data as request or session attributes, a practice I call engineered coincidences.
    Storing some assorted values in the session is not nice, but storing current data that a client works with and which is not persisted yet, in the business class, is the proper and clean approach of separation of concerns. But I must shut up and try Tapestry before making judgements. Hopefully, a "Java class, which acts as the model" can be used for other views with little modifications.
    Not sure all of this is correct but from what I understand: The data is stored in the session under the hood. Its just the way you program and access it that is different. Its accessed much as a JTextField value would be in Swing. There is one page object and one object for each component in the page. Before your code gets to process the request, these components are populated with the session specific data. Your code goes into some kind of event handler which manipulates the data. Then the framework takes over again and displays the next page reflecting the change in the underlying data. So Tapestry is a mapping between request/response oriented way of programming and propery/event oriented way of programming. But i'm not sure.
    Sorry, I corrected the typo right in the quote above.
    Its accessed much as a JTextField value would be in Swing.
    Frankly, I am not a big fan of Swing, so this advertisement won't work for me ;)
    There is one page object and one object for each component in the page.
    There is no page. The "page" is something that was created by UI designer right here right now to display data, tomorrow the output formatting may be different. Two HTML pages may be represented as a stack of four WML cards or as one rich-app wizard or a VoiceXML script. Imagine news agency and all different media like newspapers, TV, radio, etc. So, the news agency is the model, it does not even know what client may use its data and how this data will be combined with other data. I don't buy pages and page components, and this is why I don't appreciate commendable efforts of asp.net to build VB for web. But there is more to appreciate in Tapestry besides its page backing objects. Its using plain HTML for page templates is a relief.
    The existing (1.0) version of TheServerSide.com is entirely stateless – no HttpSession was allowed; the new version, 2.0, inherited this same requirement.
    Indeed. See the posting of the message:

    POST /tss HTTP/1.1
    Host: www.theserverside.com
    Referer: http://www.theserverside.com/discussions/reply.tss?message_id=154534
    Cookie: CP=*; theserverside=DB:6E:7D:A3:A4:91:F0:5B; tss-last-visit=1106861242914
    Content-Length: 259
    service=direct%2F0%2FPostD ... more+test

    HTTP/1.x 302 Moved Temporarily
    Date: Thu, 27 Jan 2005 21:52:19 GMT
    Location: http://www.theserverside.com/tss?service=direct/0/PostDiscussionReply/postReply&sp=l31148&sp=F&sp=l154534

    This nicely redirects after the POST, so refresh works correctly. I recall that about a month ago this was not the case. But why the redirected request mentions "PostDiscussionReply" and does not contain thread ID or message ID? Why it cannot be simply http://www.theserverside.com/discussions/thread.tss?thread_id=31148#154537, like a regular URL when you simply read the message?

    My point is that view should not know or care about particular server state or state before that. It should plainly show what is that in the model. This example shows that Tapestry (or particular TSS implementation) makes a difference between displaying a page from the "outside", and displaying it right after posting a reply. Why?
  36. Oops...[ Go to top ]

    It does not need a lot to blow the discussion... I am sorry for this. I guess TSS needs automatic line breaking.
  37. Detective work, odd URL[ Go to top ]

    The odd URL for the redirect-after-post is necessary to trigger Tapestry to display the "thank you" message in the upper right corner of the page. So there's a minor difference between viewing a thread, and viewing the result of posting. Off the top of my head, I can't remember what we do with the extra bits of data beyond the thread id.
  38. There is no page. The "page" is something that was created by UI designer right here right now to display data, tomorrow the output formatting may be different. Two HTML pages may be represented as a stack of four WML cards or as one rich-app wizard or a VoiceXML script. Imagine news agency and all different media like newspapers, TV, radio, etc. So, the news agency is the model, it does not even know what client may use its data and how this data will be combined with other data. I don't buy pages and page components, and this is why I don't appreciate commendable efforts of asp.net to build VB for web. But there is more to appreciate in Tapestry besides its page backing objects. Its using plain HTML for page templates is a relief.

    Yes. The question is how do you fullfill those requirements. The model will be the same regarless of how one chooses to build the view and the controller. You must capture workflow (which would be different for a stack of 4 WKL cards and two HTML pages) as easily as possible, and figure out what operations and modifications you need to do to the model as panilessly as you can. So the pages and the components i mentioned are not the model, just a good way to quickly capture what the user is doing so that you can translate that to the operations on the model. Building the controller in terms of pages and components provides a good way to do this.
  39. Tapestry just makes it natural and easy to hook everything together. At the core, its because Tapestry pages and components are stateful objects;

    Why are the pages & components stateful? Isn't a page or component the 'View' in MVC pattern and the 'Model' holds the state. What are the performance penalties involved (the IPageRecorder workings, page & component pooling vs. thread-save objects) ?

    Also on the perspective of development productivity, I have a doubt: having to maintain all the property-specifications in .page files doesn't seem good to me. Isn't it simpler to specify just the model somewhere (preferable not in XML/.page) and in the template navigate from there to the necessary page data?
  40. Statefullness[ Go to top ]

    This may not be the right medium to get into a Tapestry tutorial, but ...

    In Tapestry, pages, and components within pages, are divided into three artifacts: An HTML template which acts as the View. A Java class, which acts as the model, and an XML file, the specification, which connects the two, acting as the controller.

    The lines can be somewhat blurred; for example, the XML file is largely optional, dependening on how cluttered you like your HTML template.

    The Tapestry advantage of servlets and other stateless, operation-centric approaches is that the pages and components are organized into a tree, and that data can easily move around this tree by reading and setting properties.

    A typical servlet/struts approach involves storing temporary data as request or session attributes, a practice I call engineered coincidences. I find such approaches very limiting because it works against general principals of object oriented programming: combining state and logic in a single place. I like techniques where many small objects cooperate to achieve a goal ... that's Tapestry in a nutshell, lots of small, focused objects each doing their part.
  41. I like techniques where many small objects cooperate to achieve a goal ... that's Tapestry in a nutshell, lots of small, focused objects each doing their part.


    I also do.. great.. Straigth to tapestry books from now.. looks really great, and I have just started with if for a day now...
  42. what about jsp:include?[ Go to top ]

    Maybe it's just the examples shown in the article, but it looks as if the same thing could have been achieved with calls to JSP includes that pass in parameters, and that's a pretty old feature. It might require a "start_box.jsp" and an "end_box.jsp" instead of the wrapper that Tapestry used, but it still seems like pretty basic stuff. No offense to Tapestry -- it just seems like the JSP templating in the original version was not making much of an effort at code reuse.
  43. what about jsp:include?[ Go to top ]

    Exactly, that is what we are interesting (again without any idea of framework’s war).
    Include in jsp is a primitive template already. There are several templates based on custom JSP tags etc. So looks like it is possible to program JSP in "Tapestry" style if you need.

    Dmitry
    http://www.servletsuite.com
  44. what about jsp:include?[ Go to top ]

    The big effect of using Tapestry (and also XMLC btw) for us has been that it allows our web designers to be integral in the whole UI design process. Real separation of concerns.

    Tapestry and XMLC pages are *plain* HTML. With a jsp page, it becomes much more difficult to maintain the page visually. The jsp stuff gets in the way of the HTML designer, whereas for the developer the HTML is just something to be tolerated. And you *really* dont want a coder handling the visuals. It is definitely a different skill from coding.

    It may be *possible* to do it all in JSP, but is it *easy*? That greatly affects maintainability, error counts, etc.

    Kit
  45. I'm surprised. I thought TSS would use J2EE at all cost.

    So no EJBs?!!
  46. I'm surprised. I thought TSS would use J2EE at all cost.So no EJBs?!!

    We're using the session facade pattern ... really, the purpose of the facade is to allow the application server (WebLogic) to manage transactions.
  47. You chose JDO?[ Go to top ]

    Shouldn't you have just postponed the entire project until the EJB3 persistence spec came out? (Tongue in cheek, though some JCP members seem to think this is a rational approach.)
  48. You chose JDO?[ Go to top ]

    I applaud migration to Tapestry. Very cool!

    I guess JDO is here strictly because of political reasons…
  49. You chose JDO?[ Go to top ]

    I applaud migration to Tapestry. Very cool!I guess JDO is here strictly because of political reasons

    I'm not exactly sure what political reasons you are referring to. Did Bush slip something into Patriot Act II that I missed :-)

    JDO was chosen by the development team (note: not me, and prior to my involvement, but also a good choice in my opinion) for a number of factors including performance, access to expert support, etc. Dion Almaer is on the JDO expert panel and was influential in both the Tapestry decision and the JDO decision, but these were group decisions.
  50. You chose JDO?[ Go to top ]

    Dion Almaer is on the JDO expert panel and was influential in both the Tapestry decision and the JDO decision, but these were group decisions.
    There we are.
    Howard, I did not mean that you have selected JDO.
    IMO – JDO has little technical reasons to exist and even less to be used on TSS (any XML storage backends?), therefore using JDO here is simply a way to promote the spec.

    I just use this chance to say again and again: ORM solutions should be separated from non-ORM ones.

    PS: could TSS have a sign next to person alias that will indicate if this is a vendor of some framework or poor consumer of those products?
  51. You chose JDO?[ Go to top ]

    JDO has little technical reasons to exist and even less to be used on TSS (any XML storage backends?), therefore using JDO here is simply a way to promote the spec.I just use this chance to say again and again: ORM solutions should be separated from non-ORM ones.

    You repeated this same mantra on the other recent JDO threads. Please name some relational functionality that JDO has sacrificed in order to be datastore-neutral. If JDO completely meets the needs of users with relational databases (and it certainly meets TSS's needs), then what do you have to complain about? Why not be happy that both relational and non-relational users can enjoy JDO without sacrificing functionality?
  52. You chose JDO?[ Go to top ]

    You repeated this same mantra on the other recent JDO threads. Please name some relational functionality that JDO has sacrificed in order to be datastore-neutral.
    Reread those threads, there are mine objections to JDO as well as others.
    Why not be happy that both relational and non-relational users can enjoy JDO without sacrificing functionality?
    Abe,in what JDO implementation are you involved?
    What JDO implementation allows non-relational users enjoy full power or relational algebra? Speed?

    I am not happy about JDO by exactly the same reasons I am not happy with SOAP: hot air baloon of promises and less than perfect foundation.
  53. You chose JDO?[ Go to top ]

    Solarmetric Kodo encompasses pretty much all of the JDO 2.0 improvements (with some extensions beyond that), and is quite a bit more database-centric than a minimal JDO 1.0 implementation. One of the good things about the JDO spec is that it very explicitly leaves room for vendor extensions.

    The JDO 2.0/Kodo extensions are good for me, but don't undermine JDO's strengths. I found the runtime behavior, generated SQL, format of the configuration files, and the Kodo documentation to be extremely good.

    I have heard murmers about performance issues with JDO or Kodo. I haven't experienced these, and the ease with which Coherence plugs in eliminates my concerns. Wow -- a deployment problem you can actually solve with your checkbook.

    I've used Hibernate, Kodo and JPox JDO, Enterprise Objects Framework, BMP and CMP Entity EJBs, and written my own persistence frameworks. Now, my specialization over the last couple of years has been presentation tier, so my deepest O/R experience was with Apple's Enterprise Objects Framework. I suspect someone more specialized in O/R could identify the scenarios where Kodo was top of the heap, and those where Hibernate rocks best. Chose one, learn it, use it, master it.
  54. You chose JDO?[ Go to top ]

    Abe,in what JDO implementation are you involved?

    I work for SolarMetric, makers of Kodo JDO, the implementation used by TSS. I'm on the JDO 2 expert group, and I participate in the EJB 3 expert group. I thought my association with SolarMetric was well known by now.
    What JDO implementation allows non-relational users enjoy full power or relational algebra?

    There are many commercial non-relational JDO implementations that pass the TCK (which means they have the "full power" of JDO). In fact, the JDO 1 reference implementation is non-relational and works on binary files. SolarMetric has also created Kodo plugins to access non-relational legacy data for customers, and at one time Versant bound Kodo to their ODBMS.
    I am not happy about JDO by exactly the same reasons I am not happy with SOAP: hot air baloon of promises and less than perfect foundation.

    I think the thousands of relational and non-relational JDO users would disagree. TSS certainly disagrees.

    Until you can tell me how JDO's datastore-neutrality harms its users (either relational or non-relational), I'm afraid we can't have a meaningful debate. A debate has to be based on facts, not blind assertions. Perhaps if you cited some specific examples of JDO sacrificing functionality for the sake of datastore-neutrality, the expert group could use your comments to improve the standard. We're always appreciative of constructive feedback.
  55. There are many commercial non-relational JDO implementations that pass the TCK (which means they have the "full power" of JDO). In fact, the JDO 1 reference implementation is non-relational and works on binary files.
    ...
    Until you can tell me how JDO's datastore-neutrality harms its users (either relational or non-relational), I'm afraid we can't have a meaningful debate
    I hate to pound on the same issue again, but I still think this (small) issue is worth another comment. The issue is, again, that of queries.

    As I stated in the other thread, the power and semantics of queries depend on the underlying model. The relational model is very rich (in many respects richer than any OO language model, although it admittedly lacks inheritance and polymorphism), and has a query language that has evolved to its current power over decades.
    I still contend that it will by definition be impossible to specify/implement one query language across all available data models (even primitive ones), that at the same time provides at least nearly the complete power of SQL. Certainly, the JDO 1.1 QL did not meat this criteria - I must admit my experiences with JDO 2 are currently limited.

    christian
  56. Hi Christian
    ..Until you can tell me how JDO's datastore-neutrality harms its users (either relational or non-relational), I'm afraid we can't have a meaningful debate
    ...The issue is, again, that of queries.

    JDO 2 adds aggregates, group by, having etc to JDOQL greatly increasing is power. However what you say is true in that there are some queries expressable in SQL that cannot be done in JDOQL. For these JDO 2 standardizes the use of SQL as a query language. This gives you the best of both worlds: easy to use, portable, maintainable JDOQL for 95% of your app and raw SQL for the other 5%.

    Cheers
    David
    Versant Open Access JDO
  57. I still contend that it will by definition be impossible to specify/implement one query language across all available data models (even primitive ones), that at the same time provides at least nearly the complete power of SQL.

    JDO 2.0 has the ability to plug-in different query languages, including native SQL. Most JDO products already allow this.
    Certainly, the JDO 1.1 QL did not meat this criteria - I must admit my experiences with JDO 2 are currently limited.christian

    Why not take a look? The spec is available and there are many products implementing vendor extensions that provide most of the features of JDO 2.0.
  58. The relational model is very rich (in many respects richer than any OO language model, although it admittedly lacks inheritance and polymorphism), and has a query language that has evolved to its current power over decades.
    Inheritance exists in relational model, it maps to OO or ER modeling concepts without problems too. Implementation and conceptual model do not need to be the same, but mapping rule must be well defined ( and it is defined ). OOP language lets to use conceptual model for application implementation, but model has no asumptions about implementation language. Modeling and "good software practices" are well known many years, this stuff does not conflict with relational model. MDA (new name for old good conceptual modeling) is about the same, PIM and PSM do not need to be the same model to be "good OO sofware practice".
  59. You chose JDO?[ Go to top ]

    What JDO implementation allows non-relational users enjoy full power or relational algebra?
    There are many commercial non-relational JDO implementations that pass the TCK (which means they have the "full power" of JDO).
    Man, it looks like you have got a degree in marketing !
    I asked about [full- power of relational algebra] you answered [they have the "full power" of JDO]
    Would you like to buy a car that has full power of … a horse?

    Reading between the lines in posts it is clear that I was wrong about “political reasons to use JDO”. The choice was about a particular product: KODO, which is a very nice ORM, I repeat, ORM implementation (JDO API + KODO extensions +KODO configuration++++).
    Beware KODO != JDO , KODO is bigger and better than JDO.
    JDO == pure marketing
  60. You chose JDO?[ Go to top ]

    Yes, it is true. I found Kodo is a good product, but I can not to say this about JDO.
  61. You chose JDO?[ Go to top ]

    The choice was about a particular product: KODO, which is a very nice ORM, I repeat, ORM implementation (JDO API + KODO extensions +KODO configuration++++). Beware KODO != JDO , KODO is bigger and better than JDO. JDO == pure marketing

      KODO = JDO 2.0 (95%) + Specific extensions (5%)

       if JDO is bad => KDO is bad
       if JDO is good => KODO "can" be good
       if JDO == pure marketing => KODO pure marketing.

      ¡JDO is a specification! ¡a long paper! ¡a bunch of interfaces with a description of behavior! but ¡it is the developer view of the product!
  62. You chose JDO?[ Go to top ]

    JDO 2 is not as good as I want and it is not a "Standard", but I see some vendors think about real databases too. I do not care about political wars and I see no problems to migrate to EJB3 or to some next big thing. I see no problems to use hibernate without standards too.
    My ORM "vision" is plain SQL as query language used in consistent way with object programming language. I am sure it is possible, it is just not popular at this time (I hope EJB4 will be about it).
  63. You chose JDO?[ Go to top ]

    What JDO implementation allows non-relational users enjoy full power or relational algebra?
    There are many commercial non-relational JDO implementations that pass the TCK (which means they have the "full power" of JDO).
    Man, it looks like you have got a degree in marketing !I asked about [full- power of relational algebra] you answered [they have the "full power" of JDO]
    Please read your original message. You asked about full power or relational algebra. It's clear now that you made a typo, but how was I to know? Also, I didn't understand (and still don't) why a developer using JDO to store his objects in an ODBMS or in XML or in JNDI or in NonRelationalStoreX should care about relational algebra. He just wants to be able to store his objects, and then retrieve them again (or perform calculations on them) using queries based on his object model. That's what JDO provides.
    The choice was about a particular product: KODO, which is a very nice ORM, I repeat, ORM implementation (JDO API + KODO extensions +KODO configuration++++).
    Beware KODO != JDO , KODO is bigger and better than JDO.
    JDO == pure marketing

    Well, I agree with the first few sentences above :) Kodo strives to offer tools and services beyond the specification, like all commercial vendors do -- one of the benefits of a spec is that it fosters competition among its implementors. But as for your last sentence... thus far you have ignored my requests that you back up your disparaging comments about JDO with any facts whatsoever. As I said before, that makes any meaningful debate with you impossible.
  64. You chose JDO?[ Go to top ]

    I managed to screw up the quotes on my last message (maybe TSS can use the new power of its Tapestry engine to add a "preview post" feature :) ). Here's another try:
    What JDO implementation allows non-relational users enjoy full power or relational algebra?
    There are many commercial non-relational JDO implementations that pass the TCK (which means they have the "full power" of JDO).
    Man, it looks like you have got a degree in marketing !I asked about [full- power of relational algebra] you answered [they have the "full power" of JDO]
    Please read your original message. You asked about full power or relational algebra. It's clear now that you made a typo, but how was I to know? Also, I didn't understand (and still don't) why a developer using JDO to store his objects in an ODBMS or in XML or in JNDI or in NonRelationalStoreX should care about relational algebra. He just wants to be able to store his objects, and then retrieve them again (or perform calculations on them) using queries based on his object model. That's what JDO provides.
    The choice was about a particular product: KODO, which is a very nice ORM, I repeat, ORM implementation (JDO API + KODO extensions +KODO configuration++++). Beware KODO != JDO , KODO is bigger and better than JDO. JDO == pure marketing
    Well, I agree with the first few sentences above :) Kodo strives to offer tools and services beyond the specification, like all commercial vendors do -- one of the benefits of a spec is that it fosters competition among its implementors. But as for your last sentence... thus far you have ignored my requests that you back up your disparaging comments about JDO with any facts whatsoever. As I said before, that makes any meaningful debate with you impossible.
  65. You chose JDO?[ Go to top ]

    Also, I didn't understand (and still don't) why a developer using JDO to store his objects in an ODBMS or in XML or in JNDI or in NonRelationalStoreX should care about relational algebra. He just wants to be able to store his objects, and then retrieve them again (or perform calculations on them) using queries based on his object model. That's what JDO provides.

    Probably it because object model has no algebra. You do not need to know algebra to use SQL too, but you need it to design technology and query laguage. Information system needs some model (it needs to know math in many cases too), technology needs it too. It is common to use math to model stuff like this, but it looks like you know better ways.
  66. You chose JDO?[ Go to top ]

    But as for your last sentence... thus far you have ignored my requests that you back up your disparaging comments about JDO with any facts whatsoever. As I said before, that makes any meaningful debate with you impossible.

    You said that debates with me are impossible and still continue them. Is it marketing degree or just very good training? :)

    Facts:
    1. BackToBasics http://www.joelonsoftware.com/articles/fog0000000319.html
    This is the one reason why a store cannot work as efficiently as RDBMS;
    2. Storage transparency is a myth of the same sort as network transparency, could not find the link, but in his book Joel gives very good explanation of network transparency myth;
    3. Having efficient ORM (KODO) atop of JDO API does not guarantee efficient implementations atop of other storages ( or those engines will be RDBMS )

    “Perpetuum Mobile is impossible to build” is a hard cold fact but people continue to invent them...good luck :)
  67. You chose JDO?[ Go to top ]

    You said that debates with me are impossible and still continue them. Is it marketing degree or just very good training? :)

    Heh. Must be natural ability, because my degree is in CS and I haven't had any training!
    This is the one reason why a store cannot work as efficiently as RDBMS
    The article discusses why XML cannot be queried as efficiently as a relational store. I agree. But what is your point? I could write an article about why relationship traversal in an ODBMS is more efficient than in an RDBMS. Does that make all ORM systems useless? Of course not. There are good reasons to use relational stores and ORM, even though relationship traversal isn't as efficient as in an object database. Similarly, there are good reasons to use XML and Object/XML mapping, even though queries aren't as efficient as in a relational database. Furthermore, non-relational stores are hardly limited to XML!
    Storage transparency is a myth of the same sort as network transparency, could not find the link, but in his book Joel gives very good explanation of network transparency myth

    By definition, no differences (in store, in network topology, etc) are transparent if you delve deep enough. However, it is definitely possible to make differences transparent within a given API. For example, when you use JDBC, what difference does it make to your application code whether the database is on the same server or on a different server? None. Similarly, when you use JDO, there is no difference to most of your application code whether the datastore is an RDBMS or ODBMS.
    Having efficient ORM (KODO) atop of JDO API does not guarantee efficient implementations atop of other storages

    Of course it doesn't. And being able to compile C to efficient x86 doesn't mean it can compile to efficient PPC. No spec can guarantee an efficient implementation; that's up to the implementors. But the JDO EG is made up of members with experience on a variety of stores, and they all feel the JDO API supports efficient implementations on a wide range of systems. So rather than dismissing all non-relational JDO implementations out of hand, and by extension dismissing the entire JDO spec, why not evaluate the implementations on their own merits?

    I think now that you made some specific arguments, this discussion has gotten much more constructive!
  68. You chose JDO?[ Go to top ]

    I think now that you made some specific arguments, this discussion has gotten much more constructive!
    I just repeated that was said in other threads .
    The article discusses why XML cannot be queried as efficiently as a relational store. I agree. But what is your point?
    Very simple: if data is meant for relational access – do not store it in XML/LDAP/csv and do not hide fact that this storage (XML/LDAP/csv) is not meant for relational access and operations.

    Does it make non-relational storage less valuable? – Of course not.

     I still did no find that link but in short words it is like this: by hiding network complexity behind simple and abstract API: copy( from, to) we create whole set of problems for large files over slow and unreliable networks( modems etc.), we simply cannot handle transfer stop and resume, provide progress bar, etc.

    In other words even if you can do something (kill old ladies) it does not mean that you should do it.
  69. You chose JDO?[ Go to top ]

    Let me congratulate Howard and TSS again:It is success and I am happy that Tapestry will gain visibility among developers.

    My apologies for hijacking the thread with JDO related polemic.
  70. You chose JDO?[ Go to top ]

    Very simple: if data is meant for relational access – do not store it in XML/LDAP/csv and do not hide fact that this storage (XML/LDAP/csv) is not meant for relational access and operations.

    I'm sorry, but I fail to see how JDO tries to store relational data in non-relational stores, or how it tries to perform relational operations on non-relational stores. The whole point is that JDO isn't a relational API, it's an object API. Did you make another typo? If not, have you even looked at the JDO API? Can you point to where it tries to force relational semantics onto non-relational stores?

    I'm trying to understand your argument, but I'm not getting very far without details.

    p.s. JDO certainly could be criticized for forcing objects onto non-object stores. But that's an argument that applies to all object persistence solutions that don't sit on top of an ODBMS. Since you've implied that ORM is acceptable (which forces objects onto relational stores), it would be contradictory for you to assert that forcing objects onto other non-object stores is somehow wrong.
  71. You chose JDO?[ Go to top ]

    I'm sorry, but I fail to see how JDO tries to store relational data in non-relational stores, or how it tries to perform relational operations on non-relational stores. The whole point is that JDO isn't a relational API, it's an object API. Did you make another typo? If not, have you even looked at the JDO API? Can you point to where it tries to force relational semantics onto non-relational stores?
    It looks like you also fail to see a difference between JDO API and JDO spec.
    OK Please read #14.2 of the public draft and tell us how relational JDOQL does not impose relational operations on non-relational stores.

    Yeah, spec is clever, all the query methods allowed to throw NonSupportedQuery exception – smart.
  72. You chose JDO?[ Go to top ]

    OK Please read #14.2 of the public draft and tell us how relational JDOQL does not impose relational operations on non-relational stores.Yeah, spec is clever, all the query methods allowed to throw NonSupportedQuery exception – smart.

    First of all: no, Query methods for JDOQL queries cannot throw JDOUnsupportedOption exceptions. Second, 14.2 discusses the goals of the JDO Query API, which is in no way dependent on an underlying relational store or on anything else outside of the object model.
  73. You chose JDO?[ Go to top ]

    no, Query methods for JDOQL queries cannot throw JDOUnsupportedOption exceptions.
    My bad, they throw JDOUserException and in the different context (14.7) which makes sense there.
    Second, 14.2 discusses the goals of the JDO Query API, which is in no way dependent on an underlying relational store or on anything else outside of the object model.
    So, objects have no relationships? JDO spec and API has no grouping operations?

    That is another point: 1. Either JDO is too limited to support richness of RDBMS and therefore could work with other storages, or 2. it supports full RDBMS power and sets unreasonable requirements on implementation that uses different storage.

    1 or 2? or 3: some marketingo-implemetation confusing mix?
  74. You chose JDO?[ Go to top ]

    So, objects have no relationships? JDO spec and API has no grouping operations?

    Object relationships aren't the same as the relational algebra used in relational stores. (As Juozas will be happy to tell you!)

    Are you trying to say that you think traversing object relations and doing grouping is impossible without a relational database? If so, I think the many non-relational JDO implementors would disagree with you.
    1. Either JDO is too limited to support richness of RDBMS and therefore could work with other storages, or 2. it supports full RDBMS power and sets unreasonable requirements on implementation that uses different storage.1 or 2?

    1. If you think JDO is too limited for ORM, tell me how.
    2. Vendors of non-relational JDO products have no problems with supporting JDOQL. They're on the expert group, after all.

    Unless you can show me how JDO is too limited for ORM, or show me a non-relational vendor who says he can't implement JDOQL, you're once again making assertions without evidence. I typically like engaging arguments and feedback because it often reveals valid criticisms that can improve JDO. But I really need evidence, not just assertions.
  75. JDO?[ Go to top ]

    Are you trying to say that you think traversing object relations and doing grouping is impossible without a relational database?
    Let me bring to your attention that traversing is quite different thing from working efficiently with relational operations. And ability to group does not mean it is efficient and elegant (wanna see me dancing in ‘Swan’s Lake’ ?:) )

    Group operations are possible on non-relational structures(lets say XML) but they are horribly slow. I have experienced it firsthand and when I resorted to programmatic solution over ‘conventional’ XSLT grouping operations I got 50-100 times performance improvements ( http://kgionline.com/articles/xsl_50_faster.jsp ). This shows how efficient XML based solution is. You probably say that it is because of XSLT, nope, it is because hierarchical storage is optimized for ‘traversing’ – not for Cartesian algebra (http://db.grussell.org/section010.html) RDBMS vendors spent decades optimizing those operations, if you know how to do better than Larry Ellison will be happy to see you on payroll:)
    Vendors of non-relational JDO products have no problems with supporting JDOQL.
    I would like to hear from them, and then estimate efficiency. Everybody could claim everything, but little common sense tests could reveal interesting details: http://kgionline.com/articles/protocol_compare/doc/index.jsp
    Yeah - it is about protocols, what has it in common with JDO you will probably ask – it is very simple: implementations, which are based on sound concepts, tend to work better in terms of convenience of use and runtime performance.

    JDO notion of ‘storage ignorance’ is conceptually wrong – that is my opinion and so far I see nothing that could alter it.
  76. JDO?[ Go to top ]

    that is my opinion and so far I see nothing that could alter it.

    Whenever someone says they see nothing that could alter their opinion, I've learned to stop arguing. Think about what it means to say that you see nothing that could possibly alter your position. If you can't conceive of evidence that would change your opinion, then your opinion cannot be based on evidence at all.
  77. JDO?[ Go to top ]

    Abe, he qualified his statement with "so far". So far, your exchanges have been beneficial to some of us. Kindly, put the sentiments aside.

    Meanwhile, Howard, tapestry is beautiful, i agree, i hv been using it for some time now but....

    how do i test my tapestry pages? i know testing at the domain layer is cool but i want to test "all" my code!! I hv heard about TestAssist and Mock Objects and the current work with EasyMock and Hivemind. But i need to test my code now!! Any concrete testing examples for testing methods within a page class? and when is the improved testing framework going to be available? Thanks.
  78. While reading this thread, i am still waiting to see any valid arguments against the neutral datastore persistence of JDO from Konstantin. Must be frustrating for Abe not to reply to technical arguments. I saw one comment from Christian Sell which was valid, but which is solved with the JDO2 enhancements to querying.

    Overall its nice to see TSS using SolarMetrics solution, because it underlines my own framework decissions ;-)

    Abe, i like your straight technical and fact based postings. Keep on.

    Marc

    Note: we really need a preview feature on TSS
  79. While reading this thread, i am still waiting to see any valid arguments against the neutral datastore persistence of JDO from Konstantin.
    People tend to see the same thing differently. You could show red color to a person and Heorshe says it is … brown. Note: person is not lying.

    I hope the discussion helped both sides and undecided alike to clarify own positions regarding JDO related issues.
  80. Uh Oh[ Go to top ]

    I know testing at the domain layer is cool but i want to test "all" my code!! I hv heard about TestAssist and Mock Objects and the current work with EasyMock and Hivemind. But i need to test my code now!! Any concrete testing examples for testing methods within a page class? and when is the improved testing framework going to be available? Thanks.
    Good point. Same way you test JSPs :)

    When viewing ActiveThreads.

    Unable to resolve expression '@portal.util.PortalConfig@getEnabledGogleAd()' for portal.pages.RecentPosts$Enhance_222@53d898[RecentPosts].
  81. Uh Oh[ Go to top ]

    I know testing at the domain layer is cool but i want to test "all" my code!! I hv heard about TestAssist and Mock Objects and the current work with EasyMock and Hivemind. But i need to test my code now!! Any concrete testing examples for testing methods within a page class? and when is the improved testing framework going to be available? Thanks.
    Good point. Same way you test JSPs :)When viewing ActiveThreads.Unable to resolve expression '@portal.util.PortalConfig@getEnabledGogleAd()' for portal.pages.RecentPosts$Enhance_222@53d898[RecentPosts].

    I think if you're having to unit test your JSPs then you've missed the "Don't put logic in your presentation layer" lesson at software developer school.

    Bitty !
  82. JDO?[ Go to top ]

    Abe, he qualified his statement with "so far". So far, your exchanges have been beneficial to some of us. Kindly, put the sentiments aside.

    I didn't realize my comments were beneficial to other readers. I thought they were probably just an annoying distraction in a thread that should be about the benefits of Tapestry :)

    And since I shut up last night, posters like Henrique Steckelberg and other contributors have done a better job than I could have demonstrating the benefits of JDO. To sum up:

    - JDO has proven itself to be a very good API for ORM, as evidenced by TSS and the thousands of other ORM JDO users. ORM vendors are prominent in the JDO EG. Contrary to Juozas's implications, however, JDO 2 does not make JDO an ORM-only specification; it simply standardizes ways that ORM JDO implementations should expose certain relational functionality to their users.

    - ODBMS vendors have embraced JDO as a very good API for ODBMSs. As they should, since ODMBS vendors are also well-represented in the JDO EG.

    - JDO has also been layered atop XML, legacy data stores, and other storage mechanisms with great success. By success, I mean that JDO provides the natural object-oriented API the customers want of these solutions want, while taking advantage of the underlying store's performance characteristics. That is all anyone can ask. There is no way to make the performance characteristics of an XML store the same as those of an RDBMS. Konstantin somehow translates this as a failing of JDO, but throwing out JDO for failing to do this impossible task is like throwing out ORM for failing to make relation traversal as fast as it is for ODBMSs.

    - Konstantin says he would support JDO if it were ORM-only. So if the spec team tomorrow simply puts a line in the spec saying that JDO is ORM-only and removes the examples involving non-relational stores, Konstantin would support JDO. I don't understand this one bit. How does adding a line about intended use and removing some examples make JDO better? How does disallowing JDO on non-relational stores help anyone? As far as I can tell, it hurts users of non-relational stores who would would like to use the JDO APIs to access their data, and benefits no one.

    That's my 2 cents, for those few other readers who find my ranting beneficial :)
  83. JDO?[ Go to top ]

    I didn't realize my comments were beneficial to other readers. I thought they were probably just an annoying distraction in a thread that should be about the benefits of Tapestry :)
    It it hard to find something wrong in Tapestry and I see nothing to discuss about :)
  84. Tapestry Issues[ Go to top ]

    I didn't realize my comments were beneficial to other readers. I thought they were probably just an annoying distraction in a thread that should be about the benefits of Tapestry :)
    It it hard to find something wrong in Tapestry and I see nothing to discuss about :)

    Hey, even I can find things wrong in Tapestry ... and I'm trying to address them in 3.1. I continue to struggle with getting the message out on Tapestry ... the benefits of Tapestry are vast, but hard for people to fully grasp without getting involved (which they don't want to do unless they can appreciate the benefits --- catch-22).

    If you were in my shoes, what would you do to win over skeptics?
  85. Tapestry Issues[ Go to top ]

    If you were in my shoes, what would you do to win over skeptics?
    I would suggest:
    - stop emphasizing Tapestry benefits over bare JSP and Servlets;
    - spend some time working with other frameworks(or get familiar with them somehow else) and then make clear example when using of Tapestry paradigm is more beneficial that “Page” oriented paradigm or others ( something like your HiveMind vs. Spring philosophy blog). Every paradigm has own niche and even paradigms might play in the same niche one might be closer to somebody’s mindset than others
  86. Tapestry Issues[ Go to top ]

    If you were in my shoes, what would you do to win over skeptics?
    I would suggest:- stop emphasizing Tapestry benefits over bare JSP and Servlets;- spend some time working with other frameworks(or get familiar with them somehow else) and then make clear example when using of Tapestry paradigm is more beneficial that “Page” oriented paradigm or others ( something like your HiveMind vs. Spring philosophy blog). Every paradigm has own niche and even paradigms might play in the same niche one might be closer to somebody’s mindset than others

    i couldnt agree better. it would be lovely to write an application in tapestry and then in the other web frameworks, and analyse the code side by side and point out for example, in extricate detail, those points where the other frameworks fall short. Comparison to servlet and JSPs is a no-topic. petshop, waferproject, appfuse, manageability blog, the barracuda comparison have done well so far. but we need to reach destination. and this applies to all java technologies really. and i wonder if this kind of detailed comparison i suggest has been done somewhere.
  87. Tapestry Issues[ Go to top ]

    If you were in my shoes, what would you do to win over skeptics?
    I would suggest:- stop emphasizing Tapestry benefits over bare JSP and Servlets;- spend some time working with other frameworks(or get familiar with them somehow else) and then make clear example when using of Tapestry paradigm is more beneficial that “Page” oriented paradigm or others ( something like your HiveMind vs. Spring philosophy blog). Every paradigm has own niche and even paradigms might play in the same niche one might be closer to somebody’s mindset than others
    i couldnt agree better. it would be lovely to write an application in tapestry and then in the other web frameworks, and analyse the code side by side and point out for example, in extricate detail, those points where the other frameworks fall short. Comparison to servlet and JSPs is a no-topic. petshop, waferproject, appfuse, manageability blog, the barracuda comparison have done well so far. but we need to reach destination. and this applies to all java technologies really. and i wonder if this kind of detailed comparison i suggest has been done somewhere.
    I think a nice example that could guide us is XUL Challenge, where different XUL engines are used to create a simple calculator app. Maybe one can set something like this up, where different web frameworks have to create a simple app, even a simple calculator like XUL's, with very specific requirements, and stablish different comparison parameters: features and capabilities, speed and ease of development, code size and complexity, etc.

    Regards,
    Henrique Steckelberg
  88. If you were in my shoes, what would you do to win over skeptics?
    I would suggest:- stop emphasizing Tapestry benefits over bare JSP and Servlets;- spend some time working with other frameworks(or get familiar with them somehow else) and then make clear example when using of Tapestry paradigm is more beneficial that “Page” oriented paradigm or others ( something like your HiveMind vs. Spring philosophy blog). Every paradigm has own niche and even paradigms might play in the same niche one might be closer to somebody’s mindset than others
    i couldnt agree better. it would be lovely to write an application in tapestry and then in the other web frameworks, and analyse the code side by side and point out for example, in extricate detail, those points where the other frameworks fall short. Comparison to servlet and JSPs is a no-topic. petshop, waferproject, appfuse, manageability blog, the barracuda comparison have done well so far. but we need to reach destination. and this applies to all java technologies really. and i wonder if this kind of detailed comparison i suggest has been done somewhere.
    I think a nice example that could guide us is XUL Challenge, where different XUL engines are used to create a simple calculator app. Maybe one can set something like this up, where different web frameworks have to create a simple app, even a simple calculator like XUL's, with very specific requirements, and stablish different comparison parameters: features and capabilities, speed and ease of development, code size and complexity, etc.Regards,Henrique Steckelberg

    Emphasise Component reuse more...

    May I suggest that Component Reference be expanded into an open source 3rd party submitted library of components that have thumbnails, ratings, comments etc. Similar to sites that offer swing components or JSP tag libraries. Simpleton idea I know, but it would achieve three things.

    1. Show the active user base for tapestry and increase ppls confidence in investing the time.

    2. Shows off tapestry's ease of use, gains in productivity etc in an immediately usable way. Not everyone (grunt programmers like me) have to worry about the paradigms and academics issues, leave that to the architects.

    3. It would enable newcomers (like me) to easily integrate other people's 'flashy javascript enabled' table components, thus saving me even more time and increasing tapestry's attractiveness as a web framework.

    For example, I would like to use the code that handles link translation on the TSS website.

    Another wishlist item would be a tapestry table component that is backed by an ArrayList<ToDo> or ArrayList<ArrayList<String>>. It should be able to insert, remove or update a row in the table. I could make this myself... but I am lazy, and have deadlines... I would then check to see if anyone submitted a component like this with a generic HTML skin on the tapestry website?

    I bought the tapestry in action book over 5 months ago on a recommendation, but didn't develop anything for at least four months as I didn't have the time to prove the theory in practice and the book made my brain hurt! A component library would have spurred me on much earlier.
  89. One thing I mind in Tapestry is to the core HiveMind-ization of it. Let me prefix this by saying that I am not that familiar with HiveMind, and if I did maybe I would choose to use it anyway, but there is something in me that reflexively rejects what seems a random infiltration of HiveMind into the framework. Its ok to make for an easy integration with HiveMind, but Tapestry specific concepts should not be regeneralized as instances of HiveMind concepts. For example, the upcomming changes to the application spec where you will not define Tapestry services any more but HiveMind services. Changes like that elevate HiveMind from something you can use with Tapestry to something Tapestry is based on and tightly bound to. In the near future, as changes like this continue, looking at Tapestry one will not be able to miss the large footprint of HiveMind on it. Although that might turn out to be a good thing, it 'polutes' the framework somehow.
  90. Tapestry 3.1 and HiveMind[ Go to top ]

    Couldn't diaagree more! The integration of Tapestry and HiveMind is a wonderful thing, providing an impressive degree of expressiveness that is already allowing Tapestry 3.1 to do things in a more sophisticated, extensible and elegant manner than was possible before. It's certainly not random -- this has been a plan I've been following for nearly two years.

    However, with the exception of a few areas, such as creating new engine services, the average user will only be exposed to as much HiveMind as they desire. An easy upgrade path from 3.0 to 3.1 is an express goal.

    I think this discussion only touches on the TSS announcement in that so much of TSS is built on top of HiveMind. Were 3.1 ready and avaiable when the TSS work was done, the code base would be even smaller, and runtime performance would be even better.

    Further, the integration with Spring provided by HiveMind and Tapestry makes it just as easy to inject Spring beans into Tapestry page/components as anything that comes natively out of HiveMind.

    Further discussion about the pros and cons of HiveMind integration into Tapestry 3.1 belong on tapestry-dev at jakarta dot tapestry dot org.
  91. Tapestry Issues[ Go to top ]

    I didn't realize my comments were beneficial to other readers. I thought they were probably just an annoying distraction in a thread that should be about the benefits of Tapestry :)
    It it hard to find something wrong in Tapestry and I see nothing to discuss about :)
    Hey, even I can find things wrong in Tapestry ... and I'm trying to address them in 3.1. I continue to struggle with getting the message out on Tapestry ... the benefits of Tapestry are vast, but hard for people to fully grasp without getting involved (which they don't want to do unless they can appreciate the benefits --- catch-22).If you were in my shoes, what would you do to win over skeptics?
    I am kidding, it is possible to find something "wrong" about any technology if you know it and want to "fix" it.
  92. another fantastic thing about JDO 2.0[ Go to top ]

    Over the past 3 years I've found JAXB to be in my top 5 list of best Java technologies. For those who have not used it, you run a compiler on an XML schema and it generated interfaces and implementation classes for each data type in the schema. You can automatically marshal and unmarshal to/from XML.

    The parsing code is created by the XML-to-JAVA compiler (XJC), thus it is very efficient. So for three years I have been working with XML without writing a single parser. I threw away all my DOM and SAX code years ago.

    Then I found Apache JXPath. With this tool, I can write simple queries into the tree of beans unmarshalled from the XML (or directly on the XML if I want to). This works well for simple apps with small amounts of data and a few XML documents.

    Now check this out! With JDO 2.0 I can take the interfaces generated from the XML, and store the implementation classes in a relational databases. Thus, I can use my standard RDBMS (or any other datastore supported by JDO) to store my XML documents, and query them using standard JDOQL (which is just like lastName=="Smith" && account.balance>500). Boom, I get back the Customer instance and can marshal it to XML with JAXB.

    So now, with JAXB I can easily go to/and from XML and with JDO I can go to and from the database. My code only touches objects and I LOVE it.

    -geoff
  93. :-)

    Truley impressive integration of framework technoloiges!

    Cheers,
    Johan Strandler
    Smart Connexion
  94. I have been a TSS lurker for many years, I thought it was high time I posted something.

    On my project we chose to use Hibernate over 2 years ago. We are very happy with the results, but I have tracked JDO and JDO 2.0 to hopefully one day use a "standard" solution on future projects.

    Anyways, I thought some of you might be interested in what I stumbled across on Richard Monson-Haefel blog posted about 10 days ago The death knell: The JCP EC rejects JDO 2.0

    I thought some of you might appreciate the info given what is being said about JDO 2.0 in this arena.

    Cheers,
    Alex
  95. another fantastic thing about JDO 2.0[ Go to top ]

    I have been a TSS lurker for many years, I thought it was high time I posted something.On my project we chose to use Hibernate over 2 years ago. We are very happy with the results, but I have tracked JDO and JDO 2.0 to hopefully one day use a "standard" solution on future projects.Anyways, I thought some of you might be interested in what I stumbled across on Richard Monson-Haefel blog posted about 10 days ago The death knell: The JCP EC rejects JDO 2.0I thought some of you might appreciate the info given what is being said about JDO 2.0 in this arena.Cheers,Alex

    I agree with the reply to that post that suggests that if there is a rejection of JDO it will damage the JCP seriously. JDO was developed because there was developer demand for it. If it fails it will leave the impression that vendor pressure has been rated as more important that the needs of developers. There will still be developer need for what JDO provides. Datastore neutrality and the simplicity of JDO is something that many of us want. So, extensions to JDO 1.0.1 are likely to be developed and hopefully 'standardised' outside of the JCP. There is a danger that the widespread impression that the JCP is slow and secretive could be replaced by the opinion that it is either irrelevant or working actively against the requirements of developers.
  96. JDO?[ Go to top ]

    Konstantin,

    The only objections you have so far with JDO do not relate to JDO directly. These performance problems are due to the storage medium, and it is not JDO's fault that they differ in performance. They will have different performances wether you use JDO to access them or not! So your argument that JDO may be slow or faster depending on the underlying storage being used does not invalidate JDO's storage independence. You may access diffent storage using the same API, but of course each will have a different performance. Hell, you would get rather different performances for each RDBMs product out there, and that doesn't invalidade JDBC specification at all!

    You see, storage tranparency is about using the same API to access them all, not that you would get the same performance or have the "union all" of each storage media feature available to you. It's like Java x Assembly: if you want a common "API" to access different CPUs, you have Java. But if you want full power of CPU, fall back to Assembly and nothing will beat you. It's nothing different in JDO: you get a common API, so if you know you're going to deal with more than one storage media, that means you have to learn one API only, and all the benefits that this brings. But in case you need the full power of the storage medium, JDO allows you to fall back to SQL or whatever access API you need.

    Let's not invalidate Java specification just because it may run better on RISC than on CISC processors... ;)

    Regards,
    Henrique Steckelberg
  97. JDO?[ Go to top ]

    PS: the fact that one uses JDO or a common API to access storage media doesn't mean one doesn't have to know SQL, SAX, DOM, JDBC or whatever technology is under it.

    Just in case someone mistakes my previous post for a "JDO is the silver bullet" one... ;)

    Regards,
    Henrique Steckelberg
  98. JDO?[ Go to top ]

    PS: the fact that one uses JDO or a common API to access storage media doesn't mean one doesn't have to know SQL, SAX, DOM, JDBC or whatever technology is under it.Just in case someone mistakes my previous post for a "JDO is the silver bullet" one... ;)Regards,Henrique Steckelberg
    I do not think SQL is API or something about storage media. It is a mistake to think about databases this way from application developer point of view. I see no reason to fight with database and SQL, I see no chances to win in long term.
  99. JDO?[ Go to top ]

    PS: the fact that one uses JDO or a common API to access storage media doesn't mean one doesn't have to know SQL, SAX, DOM, JDBC or whatever technology is under it.Just in case someone mistakes my previous post for a "JDO is the silver bullet" one... ;)Regards,Henrique Steckelberg
    I do not think SQL is API or something about storage media. It is a mistake to think about databases this way from application developer point of view. I see no reason to fight with database and SQL, I see no chances to win in long term.
    This is not about fighting against SQL or database. It is about choosing the best way to store your data. If RDBMS were the only and single possible way of doing this, I would agree with you. But there are other possibilities which are better than relational database in some specific situations, depending on your requisites, constraints, etc. Worse yet, sometimes you have to mix more than one type, in order to achieve a good result. Being able to abstract from the underlying storage usually helps in such situations.

    There is not a single tool for every job.

    Regards,
    Henrique Steckelberg
  100. JDO?[ Go to top ]

    It become ORM since JDO 2, probably there are more use cases for JDO, but it is not interesting to discuss for me.
    JDO supports SQL queries too I am very happy about it, but I need more (full integration). Is it too extreme ?
  101. JDO?[ Go to top ]

    ...It is about choosing the best way to store your data...
    Not only store, but access and query.
    .....But there are other possibilities which are better than relational database in some specific situations, depending on your requisites, constraints, etc. Worse yet, sometimes you have to mix more than one type, in order to achieve a good result. ..... There is not a single tool for every job.Regards,Henrique Steckelberg

    Exactly!
    Being able to abstract from the underlying storage usually helps in such situations.
    Ooops. Why do you think ONE API and ONE query language help?
    Different storages, different API, and different Query languages exist for good reasons.


    All the “Hello world “ programs for all languages and platforms are equally convenient and simple, evil is hidden in details.
    It's like Java x Assembly: if you want a common "API" to access different CPUs, you have Java.

    Java is among many: GNU-Linux + GCC shields developers from CPU assembly and many other details very efficiently. There are also many crossplatform non-Java languages – perl, python, etc.


    PS: It looks like JDO proponents see “dismissal of JDO” as a goal of the debate, nope – personally I would support JDO if storage agnosticism will be dropped and we simply say that JDO is ORM spec.

    My goal is "Dismissal of storage agnosticism"
  102. JDO?[ Go to top ]

    ...It is about choosing the best way to store your data...
    Not only store, but access and query.
    Of course, don't store what won't be retrieved.
    .....But there are other possibilities which are better than relational database in some specific situations, depending on your requisites, constraints, etc. Worse yet, sometimes you have to mix more than one type, in order to achieve a good result. ..... There is not a single tool for every job.Regards,Henrique Steckelberg
    Exactly!
    Just to get things crearer: there are different tools like hammers, screw-drivers, but one API to access them: your hand! :)
    Being able to abstract from the underlying storage usually helps in such situations.
    Ooops. Why do you think ONE API and ONE query language help?Different storages, different API, and different Query languages exist for good reasons.All the “Hello world “ programs for all languages and platforms are equally convenient and simple, evil is hidden in details.
    Some benefits of a single API: you'll have to learn it only once, better and simpler code structure, greater reuse. I am sure there are many other benefits.
    This single API, once again, is not here to replace all the previous existing ones, it is here to be used when it fits better than using a specific one, such as when there is more than one storage medium involved in your system, or when you don't need the full power of the underlying storage, or when you need to be able to switch from one type to another.
    Just imagine if, for each kind of network connection (modem, cable, twisted-pair, coax, wireless, etc) we had a different internet protocol, not just TCP/IP. It would be a nightmare to create a web browser, for example, and everytime a new type of connection show up, you would have to change your browser code to fit it. A single API would help this adaptation a lot. It won't shield you completely from change, but would make things easier for sure.
    It's like Java x Assembly: if you want a common "API" to access different CPUs, you have Java.
    Java is among many: GNU-Linux + GCC shields developers from CPU assembly and many other details very efficiently. There are also many crossplatform non-Java languages – perl, python, etc.PS: It looks like JDO proponents see “dismissal of JDO” as a goal of the debate, nope – personally I would support JDO if storage agnosticism will be dropped and we simply say that JDO is ORM spec. My goal is "Dismissal of storage agnosticism"
    That just proves that you can be processor agnostic if you use one of those languages. You can be network connection agnostic, if you use TCP/IP. Given the correct abstraction level, one can be preatty much anything agnostic! Why can't we be storage agnostic, if we use a single API to access it?
    Of course there will always be pros and cons, just fall back to a lower level abtraction when full power is needed!

    I think you are far from reaching your goal! :)

    Regards,
    Henrique Steckelberg
  103. JDO?[ Go to top ]

    It is interesting in theory, but I do not think you can drop database and to replace with some persistent store, is it realistic using JDO ?
  104. JDO?[ Go to top ]

    It is interesting in theory, but I do not think you can drop database and to replace with some persistent store, is it realistic using JDO ?
    Juozas, JDO is not about fighting against relational data. It is about being able to use relational data, tree-structured data or flat-file data through one single API. You may come to your own conclusions of what are the pros and cons of such kind of solution, and what are the trade-offs of using it. But one can't just say this is impossible or completely unecessary and dismissable.

    Tell me something: imagine you have a client-server system which stores data at a relational db. One day your user comes to you and demand that the client side must be able to operate offline, by storing data temporarly at a local file and later updating the DB when back online, and that this local file must be in XML format, so he can inspect it in the browser, or whatever other reason he has. (don't ask me why, users are users! :) Now, wouldn't it be nice if you could reuse most of the existing relational data access code to access the new XML file-based one?

    Regards,
    Henrique Steckelberg
  105. JDO?[ Go to top ]

    Tell me something: imagine you have a client-server system which stores data at a relational db. One day your user comes to you and demand that the client side must be able to operate offline, by storing data temporarly at a local file and later updating the DB when back online, and that this local file must be in XML format, so he can inspect it in the browser, or whatever other reason he has. (don't ask me why, users are users! :) Now, wouldn't it be nice if you could reuse most of the existing relational data access code to access the new XML file-based one?
    This is prevailing line of reasoning that I call socially irresponsible.

    It does not matter that this food will make you fat and will cause heart attacks and diabetes. I do not care because YOU asked for it! And I will make it FAST!

    PS: I have noticed that some people have hard time getting allegories and accepting that everything in this world is interconnected. And that literature and extinction of species are directly connected to bugs and assumptions in someone’s code.
    I keep trying
  106. JDO?[ Go to top ]

    Tell me something: imagine you have a client-server system which stores data at a relational db. One day your user comes to you and demand that the client side must be able to operate offline, by storing data temporarly at a local file and later updating the DB when back online, and that this local file must be in XML format, so he can inspect it in the browser, or whatever other reason he has. (don't ask me why, users are users! :) Now, wouldn't it be nice if you could reuse most of the existing relational data access code to access the new XML file-based one?Regards,Henrique Steckelberg
    It is hard to imagine, but if I use RDBMS, then I use it for some reason. I can not rememer any problems related to decision to use database, but I will find a way to solve any technical problem in practice. User need solution not code, some of problems can be solved without code. Probably It is possible to buy some product to solve this kind of problem without hacking or reusing code designed for something else. Sometimes it can be more meaningfull to rewrite/regenerate code and design/optimize code for something else. I do not need help from JDO to make this kind of decisions.
  107. JDO?[ Go to top ]

    Tell me something: imagine you have a client-server system which stores data at a relational db. One day your user comes to you and demand that the client side must be able to operate offline, by storing data temporarly at a local file and later updating the DB when back online, and that this local file must be in XML format, so he can inspect it in the browser, or whatever other reason he has. (don't ask me why, users are users! :) Now, wouldn't it be nice if you could reuse most of the existing relational data access code to access the new XML file-based one?Regards,Henrique Steckelberg
    Probably It is possible to buy some product to solve this kind of problem without hacking or reusing code designed for something else.
    Even better if you could buy a product that can solve this and as a plus allow you to reuse your code designed to persist your objects, without resorting to hacking! :)

    Regards,
    Henrique Steckelberg
  108. JDO?[ Go to top ]

    +1

    It's good to see you guys clarifying JDO for those who suffered the incredible FUD spread by people who try to bring JDO down.
  109. JDO?[ Go to top ]

    Just of quriosity (and apologies from the start if I missunderstood your opinion), why do you not accept that other people than you need the JDOQL?

    Those who use object navigation and object qurey languages, and those who use relational algebra will never meet anyway. Let them both live and let live.

    Both relational algegbra inspired query languages (Hibernate and EJB3) as well as object metadata / naviagtional query language are needed in the Java community.

    Cheers,
    Johan Strandler
    Smart Connexion
  110. You chose JDO?[ Go to top ]

    Konstantint is right about it, JDO 2 is almost relational, but uses "home made" query language. Relational algebra is trivial, it has 8 functions/operations. Any linked data structure can be transformed to matrix and back, but my point is not about it. I just need portable query language, it can be implemented on linked data structures, if it is usefull for you . The best way to design it is to design it using math, but you will reinvent relational algebra again.
  111. You chose JDO?[ Go to top ]

    It was fun to read, but as I understand it is more about pedagogic than about myths. Network databases can be faster in some cases, but they can be faster for the same reason (you must know how it works). Technology implementation must know how stuff works (network/object databases is a step back from this point of view ). Relational databases solve both problems, probably linked data structures make sence too, but I think this low level stuff can be for exceptional cases only.
    But it hard to say somethink about JDOQL, it has no model and there is no way to make any informed decision to use it or not.
  112. SOAP is the EJB of XML[ Go to top ]

    Speed?I am not happy about JDO by exactly the same reasons I am not happy with SOAP: hot air baloon of promises and less than perfect foundation.
    I've posted many times that the SOAP is the analog of EJB and that XML-over-http is the analog of JDO. So don't abuse my analogy!! :-)

    Both xml-over-http and JDO allow you directly attack the business problem at hand with a minimum of configuration and superfluous interfaces/conficguration. I got involved with JDO precisely because it solved the "hot air baloon" problem that I was running into with EJB, and JDO worked so well I never looked back.

    -geoff
  113. dooop[ Go to top ]

    this
     
    "Speed?I am not happy about JDO by exactly the same reasons I am not happy with SOAP: hot air baloon of promises and less than perfect foundation."

    was supposed to be in a block quote, like this!
    Speed?I am not happy about JDO by exactly the same reasons I am not happy with SOAP: hot air baloon of promises and less than perfect foundation.
  114. You chose JDO?[ Go to top ]

    Abe,in what JDO implementation are you involved?

    I'm not going to engage in the rest of the discussion, but to be fair I don't think that Abe ever made a secret of him working for Solarmetric.

    Now go and eat your own dog food and re-read those threads...

    Oliver Kamps
    PS: And no, I don't work for a vendor. And yes, I'm on the JSR-243 EG.
  115. You chose JDO?[ Go to top ]

    Yes, Solarmetric is very active and open in community, it helps to trust this company and product.
  116. You chose JDO?[ Go to top ]

    JDO has little technical reasons to exist

    Doesn't it get tiring to continually rant about something for which you have no technical understanding whatsoever?
    could TSS have a sign next to person alias that will indicate if this is a vendor of some framework or poor consumer of those products?

    Coming from a poor consumer of a JDO product.

    God bless,
    -Toby Reyelts
  117. Why did TSS use JDO? Was it political? Well, I was part of the *group* who made the decision.

    There certainly were reasons.

    Firstly, note that we choose Solarmetric Kodo as the implementation. It happens to implement JDO, but it is a product which has a ton of features that we wanted.

    For example, the caching / performance abilities are top notch. We haven't even been able to finish tweaking things, but there are so many ways that Kodo helps you out.

    For one, check out the tools. We are able to startup a tool and watch what is going on. Tools will show you that you have setup bad fetch groups, and show many obvious problems.

    There are also very cool features around disconnected data. This enables features such as a rich client admin tool. E.g. An admin can work with content on a plane and can sync up when they get back online.

    Please remember that you can't compare "JDO" to "Hibernate" in any way. JDO is a standard. Hibernate is an implementation.

    Also, just because Kodo made sense in this case, it doesn't mean that TSS thinks that "Hibernate sucks". Far from it. We use it in many other applications. In this case we felt that Kodo was the correct choice.

    The distributed query cache, especially with the Tangosol support is pretty cool (not that Hibernate has no support for distributed queries...), and is another piece of the pie. Before this port, the queries were the ONE scalability problem.
  118. Tapestry for competitive advantage[ Go to top ]

    Do not be intimidated by the forums about how Tapestry has a steep learning curve I think its the paradigm shift that people find difficult. But when you get the Tapestry philosophy you will be very very productive.

    Converted a .net application to a tapestry based app and blew the .netters away, the .netters had not made the application very scalable and were struggling to find proper hardware to run thier software we are predominantly a .NIX environment serverside.

    Thanks Howard and Team Tapestry might just be the thing saving us from moving to asp.net!
  119. Tapestry and JDO[ Go to top ]

    There are two tutorials for developing Tapestry applications and JDO:

    Virtual Library
    http://www.jpox.org/docs/1_1/tutorials/tapestry_vlib.html

    Pet Store
    http://www.jpox.org/docs/1_1/tutorials/tapestry_petstore.html
  120. TSS used to run on a hetergeneous cluster consisting of one Oracle J2EE server, one Sun J2EE server, etc.

    Now that you have apparently deprecated EJBs, what are you using now for your servers?
  121. extinction of the big elephant?[ Go to top ]

    Oh come on don't keep our tender feet on fire. Say it, what we all want to know, what server are you using?
  122. extinction of the big elephant?[ Go to top ]

    Pretty sure he already answered that...

    Later,
    Rob Misek
    Tangosol, Inc.
    Coherence: It just works.
  123. Currently, the big elephant is WebLogic 8.1.

    Back before the sale of TMC to TechTarget, we were intending to rework the code to use a thin stack on top of Tomcat. With the sale to TechTarget, the emphasis is currently on integrating TSS better into their overall IT infrastructure. I'm much less involved than I was in the fall, and don't want to break any confidentialities.

    I actually did create a version of TSS that ran entirely on top of Jetty, and used HiveMind services and a transaction interceptor to manage JDO transactions. This version looked to be quite a bit more performant than the TSS 2.0 code we're currently using, since for most requests, only a single JDO transaction would be used ... and we did not have to detach the JDOs so that they can pass back down into the presentation layer as DTOs (data transfer objects).

    Again, I currently am serving TechTarget in more of an advisory position as they ramp up a new team to take over responsibility for the TSS codebase. Which meant I got to take some vacation, and work on my new Tapestry training labs.
  124. JDO detachment[ Go to top ]

    Howard, talking of his Jetty/HiveMind/JDO implementation:
    ... and we did not have to detach the JDOs so that they can pass back down into the presentation layer as DTOs (data transfer objects).

    JDO 2.0's detachment is a great value-added feature. However there are simpler ways if you can deviate from the "all access through EJBs" tennet.

    I'm working on an app with JBoss and JDO at present. We solve the "detach" requirement by letting the presentation tier talk directly to the PersistenceManager without going over an EJB boundary. OK, actually they talk through a query facade, but that's just a POJO which knows about all of the application's queries and returns strongly typed query results.

    So for EJB-fronted services we use CMT, and for web-fronted services we have a small amount of Struts code to begin() and commit().

    Kind regards, Robin.
  125. JDO detachment[ Go to top ]

    Howard, talking of his Jetty/HiveMind/JDO implementation:
    ... and we did not have to detach the JDOs so that they can pass back down into the presentation layer as DTOs (data transfer objects).
    JDO 2.0's detachment is a great value-added feature. However there are simpler ways if you can deviate from the "all access through EJBs" tennet.I'm working on an app with JBoss and JDO at present. We solve the "detach" requirement by letting the presentation tier talk directly to the PersistenceManager without going over an EJB boundary. OK, actually they talk through a query facade, but that's just a POJO which knows about all of the application's queries and returns strongly typed query results. So for EJB-fronted services we use CMT, and for web-fronted services we have a small amount of Struts code to begin() and commit().Kind regards, Robin.

    Please see my other note about moving away from WebLogic; I had some very clever service interceptor code that provided the necessary JDO wrapper transactions much like what you discuss.
  126. JDO detachment[ Go to top ]

    Howard, talking of his Jetty/HiveMind/JDO implementation:
    ... and we did not have to detach the JDOs so that they can pass back down into the presentation layer as DTOs (data transfer objects).
    JDO 2.0's detachment is a great value-added feature. However there are simpler ways if you can deviate from the "all access through EJBs" tennet.I'm working on an app with JBoss and JDO at present. We solve the "detach" requirement by letting the presentation tier talk directly to the PersistenceManager without going over an EJB boundary. OK, actually they talk through a query facade, but that's just a POJO which knows about all of the application's queries and returns strongly typed query results. So for EJB-fronted services we use CMT, and for web-fronted services we have a small amount of Struts code to begin() and commit().Kind regards, Robin.
    Please see my other note about moving away from WebLogic; I had some very clever service interceptor code that provided the necessary JDO wrapper transactions much like what you discuss.

    Sounds a lot like what Spring's JDO support provides: declarative transaction demarcation backed by native JDO transactions, and an OpenPersistenceManagerInViewFilter for sharing the same PersistenceManager across an entire HTTP request. Would work nicely in combination with Tapestry and Kodo JDO, running on Tomcat or Jetty :-)

    Juergen
  127. Yep, JDO, and Tomcat or Jetty. It's all you need. I've been using Tomcat + JDO + Tapestry as well as Jetty + JDO + Wicket. Works like a charm!

    nice work.

    -geoff
  128. I actually did create a version of TSS that ran entirely on top of Jetty, and used HiveMind services and a transaction interceptor to manage JDO transactions. This version looked to be quite a bit more performant than the TSS 2.0 code we're currently using, since for most requests, only a single JDO transaction would be used ... and we did not have to detach the JDOs so that they can pass back down into the presentation layer as DTOs (data transfer objects).
    Do you mean single transaction would be used for data access requests ? If you are going to reuse transaction for many HTTP requests then it can cause scalability peoblems.
  129. Do you mean single transaction would be used for data access requests ? If you are going to reuse transaction for many HTTP requests then it can cause scalability peoblems.

    No, must that a JDO transaction would be started on the first database access in a request, and reused for all database access within the same request. Invoking certain methods on the services would force a commit of the transaction (i.e., those that could perform a database update).
  130. Most trivial and clear way is to set thread local variable in HTTP filter, end transaction and release resources at the end of HTTP request. But it is possible to optimize it for scalability too, copy data you need for page to memory ( it is very small for "typical" HTML pages ) and end transaction before to write response (MVC) makes it easy.
  131. XHTML/CSS and Web Standards[ Go to top ]

    I wonder why you would bother with macros that generate a whole lot of HTML tables just for formatting and layout when there is a much more efficient way of doing it using Web Standards XHTML/CSS (see http://www.w3.org)
  132. separating structure and presentation[ Go to top ]

    Hear, hear, all the big egos around here zoom in on server side aspects but totally ignore the enourmous inefficiencies in the client side code. By adhering to clean XHTML/CSS output the server side logic could have been much much simpler. Fittingly no comments have been made on your entry as server side programmers hardly know anything about the client side aspects. There is not a single framework I know that outputs clean XHTML 1.0 Strict with all presentational aspects in CSS. The best you can find is a framework that doesn't get in the way too much if you want to follow standards. Might be an article in it "client is client and server is server and never the twain shall meet" :-)

    Cheers

    Meint
  133. Cool. And according to dice.com Tapestry is now even more productive than WebObjects ... out of 65.000 jobs there were:

    11 Tapestry jobs
    18 WO jobs
    2186 JSP jobs.

    If you reverse those numbers, you pretty much have the productivity gain when working with Tapestry instead of JSP

    PS: JSF (169 jobs :)
  134. Unable to invoke method resynchParentMessage on portal.components.PostReplyForm$Enhance_219@1c866a[PostNewsReply/postReply]: java.rmi.RemoteException: EJB Exception: ; nested exception is: com.tmc.services.exceptions.DataAccessException: Message #154390 does not exist.
    You may return to the TheServerSide.com home page.
  135. Why do you remove forum messages ?
  136. Enterprise Portals[ Go to top ]

    I had heard that you were evaluating enterprise portals for TSS implementation. May I know what went wrong? It may be a great case study if you can share that with us.
  137. unclear on benefits of tss[ Go to top ]

    The article mentions some changes that seem pretty basic to me. In doing a CGI with perl, i would call a header function that outputted a common header based on some context. Same with the footer. If i wanted a widget to be on a certain part of the page then i would call that outputted the widget code and then insert that into the right place in the page. The widget could be put anywhere.
     
    So i am not sure what the big deal is?
  138. unclear on benefits of tss[ Go to top ]

    Yes, Tapestry component model is roughly equivalent to other component models ( they all are component models after all), but ideology, implementation, and development cycle details are vastly different for different frameworks.

    It is really hard to explain why Tapestry is better in certain circumstances. Need and convenience of Tapestry somehow might be compared to the need and convenience of Portlets.

    It is very rough comparison but I hope you got the idea: at certain point we really appreciate ‘overhead’ of source control, project spec, build server etc.

    PS: Tapestry components are much easier to develop than portlets
  139. unclear on benefits of tss[ Go to top ]

    Hi

    The consulting company I used to work for has done many projects using Tapestry and JDO (JDO Genie, now Versant Open Access JDO). In most cases live JDO instances are used in the view and the applications are deployed on Tomcat. It is amazing how much reuse you can get out of Tapestry components and the sophisticated things you can do with them. Previously we used Struts and trying to do advanced web apps in that (lots of Java Script, web pages that work like GUIs) was a complete nightmare.

    Cheers
    David
    Versant Open Access
  140. unclear on benefits of tss[ Go to top ]

    Funny you should say that, we just converted our site (http://tolweb.org) from using CGI with perl to Tapestry. The point isn't that Tapestry allows you to do things you can't do in other languages/frameworks, the point is that it lets you do them easier! As a single developer working on a project for research biologists, I can tell you I'm a whole hell of a lot happier and more productive when the framework I'm using makes my life easy, and that's exactly what Tapestry does.

    One of the mantras of Tapestry is that it makes the "right" thing to do, the easy thing to do. I've found this to be the case and my work life is much more peaceful and pleasant as a result.

    Tapestry also plays nice with other products. I'm using a Hibernate/Spring combo (which also seriously rocks) that integrates seamlessly and effortlessly with my Tapestry templates.

    Peace, and Viva Tapestry!
  141. unclear on benefits of Tapestry[ Go to top ]

    The article mentions some changes that seem pretty basic to me. In doing a CGI with perl, i would call a header function that outputted a common header based on some context. Same with the footer. If i wanted a widget to be on a certain part of the page then i would call that outputted the widget code and then insert that into the right place in the page. The widget could be put anywhere.&nbsp;So i am not sure what the big deal is?
    As I stated earlier, you can get similar end results with all sorts of technology; it's a question of how much work you put in initially, and how much maintenance costs are. In fact, this reminds me of an old joke.

    The point is to make a powerful, fast, scalable, maintainable, system with a minimal amount of effort. You can cobble something together yourself for sure ... but even that's a waste of your time, and your team's time, when there's powerful solutions like Tapestry around.

    Part of the point of Tapestry is the ability of the content editors, who are not technical and have had no Tapestry training, to make changes to the site. The feedback I've gotten is of how pleased they are by the simpler HTML templates, how little clutter there is, and how easily they can make broad changes. Tapestry HTML templates are simpler and less cluttered than JSPs or any approach that tries to include code and logic inside the HTML itself.
  142. unclear on benefits of tss[ Go to top ]

    You can cobble something together yourself for sure

    Yes, because that's what i do. I just cobble shit together.

    Though i guess the separation is the key issue. Otherwise i don't see where the power comes from. It seems like another layer of indirection for things i can express easily and directly in code.
  143. unclear on benefits of tss[ Go to top ]

    I don't think Howard was attempting to disparage those who choose to roll their own solutions, rather that starting with a powerful framework will make a developer's life easier in the long run. We could also write a new compiler, RDBMS, etc. with every project we start, but it doesn't make sense because there are off the shelf solutions that get us further ahead with less work.

    My experience has been that using Tapestry frees me from writing boring, repetitive code and gets me further ahead with less work. It doesn't make sense to munge parameters in code if I have something that will do it for me and make my design cleaner and simpler.
  144. Nice URLs[ Go to top ]

    How did you get the URLs to be so nice? The URLs that are in Tapestry 3.0 are pretty messy. Were there a couple of filters written? Just curious.


    Charlie
  145. Nice URLs[ Go to top ]

    How did you get the URLs to be so nice? The URLs that are in Tapestry 3.0 are pretty messy. Were there a couple of filters written? Just curious.Charlie

    Default Tapestry 3.0 URLs suck! (There, let's just get that out of the way first off). I'm talking about bookmarkable URL's (in Tapestry terms, these are page and external links).

    However, it is pretty trivial to put a servlet filter in front that pass clean URL's down to Tapestry as it likes them.

    Here are some URL examples from the lucenebook.com site I recently built which uses a servlet filter to server-side forward into Tapestry:

       - http://www.lucenebook.com/search?query=tapestry+OR+tss

       - http://www.lucenebook.com/toc#8.7.1

       - http://www.lucenebook.com/about

    How are those for ugly Tapestry URLs? Visible URLs really should not give away the technology under the covers. URLs should be elegant. You really can have Tapestry and clean URL's at the same time!
  146. Well duh ![ Go to top ]

    Everyone knows that Tapestry 3.1 will fix this.

    Stop trying to divert the argument to your own self serving agenda you bitty loving mommies boy.
  147. Well duh ![ Go to top ]

    Everyone knows that Tapestry 3.1 will fix this.Stop trying to divert the argument to your own self serving agenda you bitty loving mommies boy.

    What's with the wierd flame? That's not in the spirit of the Tapestry community and its not welcome. Tapestry 3.1 is addressing the URL issue because Erik and others have lobbied for it, and because Paul Ferraro demonstrated it could and should be done.

    The reality is that Tapestry 3.1 is still months away from even a beta release, so approaches that work in 3.0 are desperately needed. Paul's work is great, as is Erik's integration of Tapestry and SiteMesh.

    Flames never serve anyone any good.
  148. Well duh ![ Go to top ]

    Everyone knows that Tapestry 3.1 will fix this.Stop trying to divert the argument to your own self serving agenda you bitty loving mommies boy.
    What's with the wierd flame? That's not in the spirit of the Tapestry community and its not welcome. Tapestry 3.1 is addressing the URL issue because Erik and others have lobbied for it, and because Paul Ferraro demonstrated it could and should be done.The reality is that Tapestry 3.1 is still months away from even a beta release, so approaches that work in 3.0 are desperately needed. Paul's work is great, as is Erik's integration of Tapestry and SiteMesh.Flames never serve anyone any good.

    Shut up whoever you are. Everyone knows you're not really HLS so stop pretending. The real HLS wouldn't waste his time on a lowely forum filled with wannabe java scum like us because HE IS A GOD !!!
  149. Great job, but there is still no post preview and post editing and deleting (when there are no replies to the message, for example). This is common newsgroup feature that TSS MUST have.

    Mileta
  150. How the hell do you do a DECODE in JDO?

    We use these ALL the time in our SQL.

    Mike
  151. How the hell do you do a DECODE in JDO?We use these ALL the time in our SQL.Mike
    I do not know about all JDO users, but we must use 'evil' extensions and have no chances or motivation to replace 'persistent store'. I prefer to use SQL or to generate JDBC code for realistic use cases, because it is not consistent to mix stuff. But JDO experts prefer to talk about hipotetical use cases and try to sell useless transparience for some reason. I know how to reuse code and to design applications and systems, I do not need any 'good' metodalogy and transparence from JDO experts.
  152. How the hell do you do a DECODE in JDO?We use these ALL the time in our SQL.Mike
    I do not know about all JDO users, but we must use 'evil' extensions and have no chances or motivation to replace 'persistent store'. I prefer to use SQL or to generate JDBC code for realistic use cases, because it is not consistent to mix stuff. But JDO experts prefer to talk about hipotetical use cases and try to sell useless transparience for some reason. I know how to reuse code and to design applications and systems, I do not need any 'good' metodalogy and transparence from JDO experts.
    Hey Juozas, a couple of things:
    - nobody is telling anyone to replace anything. Again: don't replace your RDBMS, PLEASE! Even if you decide to use JDOt, DON'T REPLACE YOUR DATA STORAGE! :)
    - that case I gave as a example is not hipotetical, it is real (as much as socially damaging, ain't life tough? ;)
    - JDO allows you to use "evil" extensions, if you need them, no problem at all
    - transparence may be useless FOR YOU, but not for everyone else
    - many people have already stated the many good reasons for transparency, but you can't understand them for some reason
    - if you don't like or need JDO, it is ok you don't use it, but there are many others that DO like it and DO need it

    Juozas, try to step out of the box for a while and understand that there are other situations and requirements and type of systems other than what you have done your entire life. It is not hipotetical, it is real, even if you have never seen it before, and never see it again in the future... ;)

    Regards,
    Henrique Steckelberg
  153. I need and I use many things. I am just asking for features, I do not need and do not want to disucuss transparence, but any discussions ends with this nonsence for some reason. I need very simple thing, good SQL integration including DML.
  154. I need and I use many things. I am just asking for features, I do not need and do not want to disucuss transparence, but any discussions ends with this nonsence for some reason. I need very simple thing, good SQL integration including DML.
    For someone who doesn't want to discuss about transparency, you seem very responsive to posts regarding JDO, a specification that is all about providing this "uneeded" and "nonsense" transparency to many happy developers and their existing and nicely working systems.

    Regards,
    Henrique Steckelberg
  155. How the hell do you do a DECODE in JDO?We use these ALL the time in our SQL.Mike

    Ok, I had to look up DECODE on Google before I even knew what Mike was talking about. The reference I got was: http://www.metrokc.gov/gis/kb/Content/SQLTipDecode.htm

    Here's how I would do that example with JDO (no JDO 2.0 features necessary for this one!).

    Firstly define an enumeration class in Java.

    public class JudicialDistrict {
    public static final JudicialDistrict NORTH_EAST = new JudicialDistrict("North East", "NE");
    public static final JudicialDistrict SOUTH_EAST = new JudicialDistrict("South East", "SE");
    ...etc...
    public JudicialDistrict(String name, String key) {...}
    public static JudicialDistrict fromKey(String key) {...}
    public static String toKey(JudicialDistrict jd) {...}
    public String getKey() {...}
    public String getName() {...}
    }

    Then, in any class which physically encapsulates a JudicialDistrict key logically encapsilates a JudicialDistrict bean.

    public class CaseFile {
    private String judicialDistrictCode;
    public JudicialDistrict getJudicialDistrict() {
    return JudicialDistrict.fromKey(judicialDistrictCode);
    }
    public void setJudicialDistrict(JudicialDistrict jd) {
    this.judicialDistrictCode = JudicialDistrict.toKey(jd);
    }
    ...etc...
    }

    I use static methods on the enumeration class because these can detect and return null, preventing (a) NPEs in clint classe, and (b) distracting null handling code in client classes.

    The enumeration (JudicialDistrict) is NOT a persistence-capable class. However there may be a table which contains JudicialDistrict rows, and there may be foreign keys from the tables of client classes to this table in order to enforce refferential integrity in the datastore.

    So, DECODE is easy. Next question?

    Kind regards, Robin.
  156. Working with persistent enumerations[ Go to top ]

    And of course, this approach is entirely testable with JUnit and without any connection to a database.

    I find being able to test my domain objects without a database is extremely helpful.
  157. How the hell do you do a DECODE in JDO?We use these ALL the time in our SQL.Mike

    Robin already answered with one approach, but there are much simpler ways. Most JDO implementations provide an easy way to automatically transform a simple value into another simple value. For example, you might have a persistent field called 'isMale' of type boolean mapped to a CHAR(1) column that stores 'M' or 'F' for male and female. You can set up the implementation to do the transformation from 'M' to 'true' and 'F' to 'false' and back again transparently. Then you don't need DECODE in your queries anymore, because the implementation does the decoding for you. When querying on the isMale field mentioned above, you'd query on its Java boolean value, and the implementation would turn 'true' into 'M' and 'false' into 'F' when generating its SQL.
  158. There are many things in SQL and it is possible to find workaround for any case, View can help to "hide" any more complex SQL construction, but SQL interface is usefull for any "persitent store". The reason to use is very simple, it is integration with mature tools and this way is consistent for all programming languages. I am sure it is possible to implement it for XML or flat files too, there are many opensource SQL parser implementations, you just need to implement some wrapper for "persistent store" to make it useable from database tool or "legacy" application. It doe's not break any tranparience.
  159. Bleeee :-( I run www.abclinuxu.cz which has over 4 megahits a month on single P4 1,6 GHz with 512 MB RAM. And I guess, that it is much larger application than serverside with larger data .

    On the other hand I dont like my homegrown servlet based system too. Thanks for this article, I will take a look at tapestry.
  160. No HttpSession?[ Go to top ]

    The article mentioned that there was a requirement for no use of HttpSession, so the application can be stateless. I assume this means that the application could be on a multi-server farm and a user could start a session/login on server A, then be directly to server B (via a load balancer or something) and server B would be able to tell that the user is already logged in. How did you go about implementing that?
  161. No HttpSession?[ Go to top ]

    The article mentioned that there was a requirement for no use of HttpSession, so the application can be stateless. I assume this means that the application could be on a multi-server farm and a user could start a session/login on server A, then be directly to server B (via a load balancer or something) and server B would be able to tell that the user is already logged in. How did you go about implementing that?

    TSS uses a cookie for authentication, and uses query parameters (often in hidden form fields) for the rest. The outer firewall passes requests to the servers in the cluster in a round-robin fashion.
  162. No HttpSession?[ Go to top ]

    TSS uses a cookie for authentication, and uses query parameters (often in hidden form fields) for the rest. The outer firewall passes requests to the servers in the cluster in a round-robin fashion.

    So I assume by that you mean that authentication can happen on server A, a cookie is generated, and then if server B receives a request with that cookie, it can verify that it is a valid cookie, even though server B was not the server that generated the cookie?
  163. It would be great if the group-discussion/tss-experts-thought process can be shared for choosing a Tapestry over other competing webframeworks like Struts/WW2/JSF etc..?


    Which framework(s) was TSS using earlier?

    3 cheers for successfull migration..
  164. But I've heard good things about Tapestry. Is the JDO in
    the Web Container or the EJB Container? Do you plan to convert/refactor to EJB3.0? Are you using any J2EE APIs?
    Is this a statement you are making to use Tomcat and throw away Weblogic?
  165. Ground breaking JSF?[ Go to top ]

    That's pretty funny ... JSF breaks no new ground; that ground has been broken and tilled by Tapestry and other open-source projects for years.

    If JSF was the right choice for TSS, that's what TMC would have chosen. Luckily for them and for myself, they saw that Tapestry was the correct solution for TSS.

    Currently, JDO is being used within the application tier, behind a EJB facade. A simpler stack is the goal, but I've moved on to other work, primarily, while a team at TechTarget spins up to take ownership of the code and its future direction.
  166. Glad I made you laugh[ Go to top ]

    It's just that some of us (at least 1 of us) are more interested in the J2EE standard APIs. That's how we work. I was under the impression that's what TMC was all about when Floyd and Ed got together and created TSS.
  167. Glad I made you laugh[ Go to top ]

    It's just that some of us (at least 1 of us) are more interested in the J2EE standard APIs. That's how we work. I was under the impression that's what TMC was all about when Floyd and Ed got together and created TSS.
    Why do not you consider Tapestry as a candidate for "Standard" J2EE? :)