Splitting web4j in half - request for comments

[John O'Hanley]

Hi,

I'm considering splitting web4j into 2 jars.

The problem: the database/sql tools in web4j are pretty good. I, and
others, would like to be able to easily use those tools in non-web
contexts:
- command line applications
- Swing applications

However, that's not currently very easy. The reason is a design flaw
in web4j - the data layer tools have knowledge of ServletConfig, for
config information.

There are other aspects of config in general that I would like to
improve as well, to allow people to place config somewhere else than
the web.xml file.

The idea is to split off the code that deals with 2 things :
- model objects (SafeText, Decimal, and so on)
- transferring these model objects into and out of a relational
database (the data layer)

IF that is done, however, then it's natural to use new package names,
corresponding to the new jar. Thus,

hirondelle.web4j.model..

might become instead :

hirondelle.data4j.model

For existing apps, that's not the end of the world, but it is a
significant amount of pain, in order to change the imports to the
changed package names.

How would you feel about this sort of change, if this were done?

- John

[Marcio Duran]

I'm still getting to learn how to use WEB4J but I'm really excited
because I can learn something quick and low learning curve!!

Thank You

John!




On Feb 26, 4:50 pm, "John O'Hanley" <webmas...@javapractices.com>
wrote:

[IvanL]

Hi

Is this still an actual issue? The standalone db layer would be really beneficial.

In my opinion, even if the package was left intact the benefit from separating the db layer from the web-app layer would significantly outmatch the presumed inconvenience from the the current package name (hirondelle.webj.model, etc). What is it that delays this refactoring? Could I possibly give a hand?

суббота, 26 февраля 2011 г., 21:50:25 UTC+2 пользователь John O'Hanley написал:

[John O'Hanley]

Yes, this is still an open and important issue.

It hasn't been addressed yet, but it is high on the list of possible
future enhancements.

I simply haven't had the time to do it; I did some preliminary
explorations about 2 years ago, saw that it was a large change to the
code base, and did not pursue it further. My guess is that it would
take me 2 months to do it properly (working part time in the
evenings).

As far as cooperating on the code base.... I appreciate the offer, but
in this case I must admit that I'm not very enthusiastic about it.
This change is rather large scale, and has, I think, a much larger
number of ripple effects than usual. Another aspect is that, for me,
design and construction are deeply entangled with each other; I
wouldn't have any big up-front design that could simply be implemented
by someone else later...Sorry about that. I understand if you are
frustrated by this answer.

John.

[IvanL]

Alright, thanks

суббота, 26 февраля 2011 г., 21:50:25 UTC+2 пользователь John O'Hanley написал:

Hi,

[John O'Hanley]

I will do my best to fix this for the next release.

- John.

[John O'Hanley]

FYI - I have worked on this in the past week. There were indeed a lot of small internal changes. They will be part of the next release, which might be in November. There was no need to create a separate jar.

This issue was a big architectural emabarrassment to me, and I will be very glad to have it fixed.

You will be able to re-use your existing model objects and DAO classes outside of the servlet context. But your Actions will not be re-usable.

The addition to the web4j API is a single call, which takes two maps:
Db.initStandalone(Map<String, String> aSettings, List<String> aRawSql)

After you call that method, you will be able to use the data layer in the usual way.

You will need to define a ConnectionSource class too, of course (in the usual way).

- John