> shawn wrote:
> > The Maven site looks quite nice.
>
> We could improve it with some Playmates pictures somewhere ;^)
>
> > After we get a "stable" release and the new site up, why don't I
> > mention it on Tocmat, Mysql ect lists with the features it offers.
>
> +1
+1 from me too!!
>
> > Speaking of releases, are we going to get out a 1.1.3
> release before
> > we start adding a "not core" mechanism to add plug-ins. I
> would think
> > that the plug-in design would be at the l.2 level to more
> accurately
> > reflect the amount and scope of changes.
>
> +1
Would agree.
> At this point, I suppose that DbForms should start to gain
> "visibility". A 1.1.3 stable(*) release, a "Maven site" and a
> bit of advertisement on
> other projects' lists could help in this process...
>
> > In hindsight, maybe 1.1.3pr2 should have been 1.1.3. That way, we
> > wouldn't have to come out with a 1.1.3 release with a new plugin
> > design. The other choice is seems like is for 1.1.3 to
> come out with
> > Henner's JasperReports being part of the core. Maybe the best way
> > would
>
> +1
Would aggree
> I suppose the latest dev release is quite stable and there are no
> "serious" known bugs around; the latest issuses (navigation) were
> resolved by the documentation process... ;^)
> A "stable" release could help some new developers to "put
> their hand" on
> the project without having to listen to their boss' complains about
> "unstable open source projects" ;^)
Yeah!!!
>
> > be to leave Henner's work as core, release 1.1.3 and then
> target 1.2
> > for the new plug-in system.
To clarify:
The new JasperReport feature is just a new servlet. No other part of
dbforms depends on it. Only the neccessary JasperReport.jar is new in
the depend dir.
To add things wich are independend from the core version we should think
about a directory structure for the extensions, e.g.
Extensions
JasperReports
dependend
src
doc
OtherExtension
dependend
src
doc
Then me can setup the build file to build the core + extensions.
>
> At the moment, the only thing I can think about a "plugin
> system" is to
> avoid dependencies between "core classes" with "not core"
> classes. I think it's possible to use some design pattern to
> try to prepare a
> better design for a future plug in system.
> For example:
>
> - FactoryMethod or AbstractFactory pattern to avoid direct object
> instantiation;
> - Strategy pattern to incapsulate strategies (algorithms) and
> make them
> interchangeable;
> - data access object pattern to incapsulate JDBC code into objects
> without spreading SQL stuff around;
>
Good idea, we should do so everytime we reach a point were we want to
add extensions which need to interact with the core part.
Regards,
Henner
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
DbForms Mailing List
http://www.wap-force.net/dbforms
