On Jun 9, 2008, at 7:00 AM, Alan Gutierrez wrote:
> Stripers
>
> I'd like to develop in Stripes. Imagine a typical web shop that does
> a website for a firm, but fills in the blanks with Stripes. Wouldn't
> it be great to have a Stripes CMS that approached some of the
> functionality of WordPress if not Drupal?
>
> Anyone developing such a monster? If not, what CMS would you
> recommend to use with Stripes development?
I can talk about mine, it's not OSS either, but it's all my code (so
in theory could become OSS).
I had some primary drivers for my system.
-- Structured content
-- Time based publishing
-- Support user change
-- Separate CMS from the actual web site.
Effectively my goal was to provide a back end to a JSP coder. For my
sites, the vast majority of the pages are static, using a themed page
with individual parts of the page being dynamic.
With that in mind, the base goal was to provide a generic back end
and then build a site on top of that, but the site would in fact
mostly just pull content from the back end.
What I have meets those basic goals (though it's far from perfect).
With it you can:
Define structured content: This means I can make a piece of content
that has, say, Name, Description, 2 images, and a PDF. This content
is defined through Content Templates. Each content can have an
arbitrary number of fields, and also has an attached velocity script
that can be used to render the final content.
Define categories of content. Each category can have 1 or more
Templates associated with that category.
Define Page Templates: These allow you to create fill in the blank
page templates that can be used to generate JSP pages within the site.
Define Pages: this allows you to create the actual pages.
Create Stories: The fundamental content artifact. You select a
category for each new story, then a form is created from the default
template of the category. At that point you can fill in the various
fields. I have pickers for images and things like that, date fields,
numbers, etc. No real validation (save that numbers are numbers, and
dates are dates). If a category supports more than one template, you
can change the template on the fly, the form will reload, keeping the
like fields (if name was on the old template, it will remain in the
new template). I also have a (weak) wiki markup system that works
within text blocks.
Finally, I also have a search engine for stories and PDFs attached to
stories.
All stories have start and stop dates and an active flag.
Each of these bits are in various levels of maturity.
In use, the site itself is basically a set of JSP pages with some
tags to load the content. like <t:stories categoryName="In the News"/
>, will populate a "stories" collection that the JSP can then
iterate and format however it likes using JSTL or scriptlets. The JSP
has access to the raw components of each story, as well as a
formatted version of the story (if it happens to have a velocity
script defined).
I also have a <t:story categoryName="In the News" id="${param.id}/>
which gives you the latest story for a category, or, if 'id' is
passed in the url, it will return the story with that ID (assuming
it's active and within date).
Combined with JSP tag files for templating, it's not uncommon for a
page to look something like: (minus JSP headers)
<t:story categoryName="In the News" id="${param.id}"/>
<t:page title="In the News">
${story.rendered}
</t:page>
For my sites, when I want more sophisticated work, I just dump in to
raw stripes actionbeans to supplement the JSPs. The users obviously
can not really affect the logic of the action beans (as they don't
have the source), but they can do whatever they like with the JSPs.
I'm not really happy with that distinction.
The CMS doesn't have much caching beyond whatever JPA provides, save
my custom actions which are heavily cached.
I don't have anything like a menu system or navigation system within
the CMS. Pages, while in fact just JSPs are stored in the DB I don't
do anything with that, save a little bit for the Wiki markup stuff.
It's implemented as a CMS EAR component with has the CMS management
WAR as well as the core of the CMS, and the applications are
individual WARs talking to the CMS via Remote EJB. This works pretty
well, and lets me keep a modicum of isolation between the two
systems. While rare, it's nice when I'm working solely on the front
end site and only have to redploy the WAR, while the CMS stays
untouched.
Beyond basic goals, the system has basically evolved rather than been
engineered as a cogent whole from the ground up.
I am mostly happy with the system. I would like for it to be easier
for users to create logic on their site beyond hacking scriptlets on
JSPs, but I think ActionBeans are a bit too much for that. I think
the Model 1 style works great for most simple "web sites". The wiki
markup needs more work. I would like to be able to relate structured
content to each other (the ever terrible creating a DB within a DB
pattern -- sigh).
At the same time, I think it would be good to step away from JSP and
move over to a pure velocity or maybe FreeMarker system. I haven't
tried enough with either one to see how well it would work,
especially in regards to how I use tag files today (which I'm quite
happy with).
I'd like more ubiquitous caching in the system. I'd especially like a
tiered, related caching system where I can change one piece of
content and the system "knows" all of the affected pieces and dirties
them for me.
It could use a good, solid EMail subsystem as well (mass mailing,
mailing list management, etc.). IF anyone knows of a reasonable
system like that in Java (For free) I'm all ears.
I have thought about redoing the entire thing (yet again) with a
combination JCR based back end and Javascript and Velocity based
front end. But I haven't done any work on that. The CMS back end
would most likely remain in Stripes, but "sites" would be built on a
combination of Velocity presentation and Javascript logic, all stored
in a JCR repository.
But when I think about that, I serious consider "why don't I just do
this in PHP" or perl or whatever. And I don't have a really good
answer for that save I'm not real experienced in those systems, but
they would most likely be more readily deployable.
Aaron and I talked a little about the idea that it might be neat to
be able to write Stripes Actions within JSPs. He's done some work on
this, but it's a bit nasty. I was thinking of using the Stripes
binding logic as a simple utility where you pass it a Request and an
Object to populate, and it does all of the work, perhaps returning
validation details or something. I don't know if I'd have rely on the
form tags or not. But it would make it a bit easier to write JSP
Model 1 style applications.
I have given no thought to a module system, or how that would be
done, or how they work. From the ones I've seen, they're just hooks,
interceptors, callbacks, and listeners that are wantonly plugged in
to the system that users can dump code in to. A Javascript system
would readily support that I think.
Anyway, that's what I've been doing.
Regards,
Will Hartung
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
