I am very much interested in the "blogs tool" idea and willing to
contribute. As I had mentioned, I use Roller as a framework for
custom blogging solutions and would very much welcome greater
separation of concerns and componentization. I haven't looked at 2.0
codebase in great detail yet but I found 1.x codebase a bit
difficult to extend with its liberal use of private and static fields/
methods. On several occasions I had to copy entire classes.
I am a huge fan of Spring and would love to see "dependency
injection" incorporated into Roller. In fact, I can contribute a
Spring-based implementation of org.roller.model.Roller interface
which dispenses manager classes obtained from a Spring XMl-based
factory. This allows to plugin custom business logic implementation
by editing an XML file.
I have a few other suggestions to make Roller a more robust and
extensible product:
1) Clustering: This involves adding distributed caching and search
indexing. I had to solve both problems (not as elegantly as I'd like)
but it's enough to get us started.
2) Transaction management: Currently connections/transactions are
started/closed by Servlet filters which tightly couples business
logic tier to the web tier. Spring elegantly solves this problem, by
the way.
3) Removing persistence/business logic from POJOs (like save()
method). I recall a discussion about this at some point where it was
decided we wanted "smart" POJOs. The problem with keeping such logic
in POJOs is that it makes it difficult to deploy Roller in a truly
distributed environment (eg: rich client accessing managers wrapped
in Web Services and/or EJBs).
Let me know if any of these are of sufficient interest and if I
should propose them in greater detail.
Max
On Nov 21, 2005, at 11:34 AM, Anil Gangolli wrote:
This is likely to be controversial territory. Consider this a
brainstorm, and not an expression of firm opinion.
I confess I'd been thinking along similar lines for Roller 3.x or
possibly 4.x, at least that we should be considering rearchitecting
around a data/event model that allows developers to hook in at
natural points in the lifecycle of blog entries and possibly other
types of elements in a blog model. This would involve factoring
out elements of the app and developing more of an "engine" as the
heart of the app, producing a core which may eventually be
separable from Roller the app. Roller itself arguably already
contains two apps: the "blog authoring/publishing app" and the
"aggregator app" (Planet). (Both of Miguel's suggestions seem to
involve extensions along the aggregation side more.)
However, my ideas around this have remained pretty vague, and I'm
not positively convinced this is a good idea for Roller the app(s?)
and the present Roller community, though it might be very good for
a developer community spawning other apps built around an ASF blog
tools core.
On a related (I think) note, I had also been thinking (again
vaguely) about using Spring dependency injection (just the core
bean factory and app context stuff) as a mechanism for providing
more configurable pluggability, initialization, and clean
separation of components. [Side note: Spring is ASLv2-licensed, but
another jar to download.]
--a.
Miguel A Paraz wrote:
On 11/9/05, Dave Johnson <[EMAIL PROTECTED]> wrote:
If people want to add their own feed persistence subclasses
based on
ROME Modules, I believe it would be good to make this a plugin
mechanism.
Good point.
Hi,
I'd like to generalize the concept of plugins or an extension
mechanism. I see Roller as a framework for feed-related apps, which I
believe is closer to the "spirit of the ASF" than a self-contained
app.
I would like the capability to write new apps on top of Roller but
minimizing the impact on the core source code and build process (not
the case with the code I wrote for geoaggregation - had to tweak
build.xml)
Can I work this into a proposal? I would like to work on the
following
as ASF-style licensed projects:
1. The geoaggregator - which I can share right now, but it's a
bunch of hacks.
2. Integration with Nutch - I'd like to index the URLs the feeds
point
to. Of course, this can be done without integration. Nutch can fetch
URLs from the SQL database.
