TheServerSide is a major source of design pattern (atleast for me) and many widely used patterns started out here.
I think the support for documentation and discussion of design patterns should be vastly improved in order to allow serious discussion, and IMHO the community will gain alot from the extended support. Areas that I think require improvement are:
1. Submittion of design patterns should be in some standard form. Currently the scope, motivation, solution, implementation notes, etc are all scattered through the freely-typed text. It makes patterns much harder to read and to seriously analyze. A standartized form doesn't just help the readers - it also helps the author organize the pattern in a logical way and gain insights about what's truely important and what is specific to his own application.
2. There should be some way of adjusting the pattern description (maybe by author only). Design patterns are recurring best practices. I think the reason the Patterns section has been so succesful is that it enables people to recognize these reucrring best pratices. When someone posts a pattern, usually atleast a couple of people have allready used it and are able to comment about different implementations, expirience with the pattern, etc. It's unreasonable to think that after all this debate the pattern will remain exactly as it was. Different people use the pattern from different perspectives, and the pattern description should capture all of these in a generic way.
For example, I remember that when the Patterns section was just starting out WebLogic was just about the only app server people actually used. As a result of this, about one of every two patterns violated the spec by assuming commit option A. I even remember such a mistake appearing in one of the first TSS news-letters (and then rectified in the next one). That's natural and there's nothing wrong with it, but right now when people go to have a look at these patterns they will see the deprecated version. Only if they read 30-40 messages down, they will get to the first traces of something being wrong. If the author could edit the pattern after the community discussed it, you could simply read the pattern without worrying about the entire discussion that follows.
Anyway, TSS is doing a great job as it is (IMHO). Keep it up :)
You do realize that the enhancement you are requesting will mean that TSS can no longer run on Read Only Entity Beans, as you would like the original pattern post (formatted and separated better as well) to be changable (by the author)!
Since I think TSS runs on WL, we should ask Floyd/Rikard if they feel like committing Sepukku, so to speak... otherwise there is an ACE in the hole.
By the way, I totally agree with your enhancement idea, the pattern threads get long and the author (like myself) usually wishes he could incorporate some stuff into the original post. Did you notice, incidentally, that I tried to keep my recent pattern (ACE cache) in tune with the headings used for design patterns typically? I, for one, will be able to seamless migrate my pattern to your new format ... ;)
I think the idea is great, and the only problem with it is performance, especially when we move to a clustered solution. I.e. we won't be able to cache data much.
However, since we're considering moving to a model with JSP caching instead of Entity caching, that may not be such a big problem. Whenever the entities are accessed they will use un-cached data, and whenever JSP's are viewed in forums the cache will do its thing. Thus the impact should be not so bad.
Keep it coming! We want as many ideas as you can come up with (ahem, within reason anyway ;-)
My question is then, how will you expire the cached JSPs (cached as HTML I'd think) when the certain related entities are updated?
It just seems like the same problem at a different layer ... the only difference being that you could use something like NFS to accomplish the cluster-wide part of the expiry.
But you'd still need to keep track of what pages were related to what entities, in some kind of registry, and then use the registry to zap the pages when entities were updated ...
I was planning on using OSCache:
I.e. either a timeout, or using explicit expiry of pages.
The main difference is that with this, there's two levels of data usage, one which is cached and one which is not. I can do CUD processing on EntityBeans, and use the JSP cache for the Read-Only stuff.
I apologize for the delay in replying to your excellent and well thought out post. I have been in the process of completing my own book on EJB Design Patterns, which I plan to post into the patterns section of TheServerSide in full HTML format.
A standardized template for patterns could definitltly work. However we would then need to provide multiple choices of templates (not everyone likes to use the GOF format, some like Alexandrian and variations of both). Are you suggesting a hard coded form for submitting a pattern , or just providing some guidelines?
Editing the patterns afterwards is a good idea. I am also impressed that you remember about my pattern mistake with regards to commit option A from so long ago. You are truly a long time valued member of TheServerSide!
If we do edit a pattern, perhaps we should provide some kind of visible 'change log'. My concern is that replies to a pattern will be made, and then the original author would edit the pattern, then the replies will become out of context and sit there polluting the thread. Any ideas on how to avoid this?
Don't worry about the delay, Rickard as allready filled in for you :) Of course, your reply was also very interesting.
I agree that one hard-coded format may not be a good choice, because there are atleast two or three common formats out there. Even if you incorporate the majority of them, there is still a question of whether or not to allow authors to change this form. I thought about two options:
1. Load the message body box with the standard form allready in it (i.e, the titles, etc) and let the author edit it.
2. Use a hard-coded form that the user has to fill.
Of course, in both options more than one form may be supported. The problem with the first option is that you lose semantic information, which will make it harder to add smart-searching, pattern-dependency views, etc. The problem of the second is, of-course, the loss of flexibility.
An XML format for the pattern could be a nice touch, but I am not aware of any such format and creating it may be outside this scope.
The reason I remembered your error in particular is that it is about the only one I ever noticed in TheServerSide's content. And also that I had to argue in the patterns section for about a week to convince people there really is a problem (I am one of the few who were not using WebLogic at the time :) )
I agree about the change log. One option is to keep different versions of the pattern and have replies address specific versions. This is easier than giving a "merged" view. You could try to implement a merged view like MS Word's using plain HTML... Good luck... With CSS it shouldn't be that hard, I think.
Anyway thanks for taking the time to reply.