Hi Steven,
I'm glad to hear the first part of that, and yes, I did notice a
lot of examples in the release notes, which are great. My harsh
comment was based solely on the parts of the framework I've tried
to use. The template system is quite well documented, enough so
that I felt confident editing the Wiki to clarify the one thing I
found I had to ask on the list about. And the simple blog movie, as
I mentioned, is a very good introduction. It was therefore pretty
jarring that the first thing I tried to do after finishing the
tutorial (add database authentication) was essentially undocumented.
Indeed. I hope that someone has the time to document it properly and
otherwise I'll try to take a crack at it when I come back from TSSJS
Europe.
As was the thing I tried to do after that (get rid of the URL
decoration). And the thing after that (beefing up my model with
some more complex database access).
It is entirely possible that I just happened to hit the worst-
documented three parts of the framework all in a row.
You sorta did :-/
A project with the momentum of Spring, with their amount of
contributors and commercial companies behind it, is of course able
to provide a lot more in terms of books and user guides. There's
only so much that a small team of motivated developers can do for
free in their spare time. However, if you do feel that some areas
need to be improved quicker, you're always welcome to contribute
to the effort and document your findings either in articles or
Javadoc additions that you can send to me as patches.
I am happy to update the documenation in places where I feel like I
have a solid enough understanding of the subject to make a useful
contribution. And FYI, my comment about Spring was more about the
Javadoc than the books and user guides (though those are nice too).
Sounds like you have that problem under control for new code, but
as a new RIFE user I have no way of knowing in advance what code is
new and what code is old, so from my perspective the documentation
is a random roll of the dice: will there or won't there be any
documentation for what I want to do?
I hear you, really do, though good documentation is very time-
consuming to write. Many open-source projects just add one-liners as
Javadocs, which doesn't really benefit you much as a user. Once in a
while me or someone else takes out some days and completes the
Javadocs of older APIs that were committed without. Sadly it's very
difficult to dedicate time to that since there's no real benefit for
it during customer projects. Other advancements that I and others
make to RIFE are mostly driven by real problems in real projects, and
writing Javadocs for those along the way can be justified during the
implementation. Even in those cases there are limits though.
Interface21 on the other hand, solely bases their business on Spring-
related things. They give courses, seminars, on-site training,
audits, ... they have a real business incentive to invest money in
people writing extensive documentation and even have paid developers
that only do things like that. For RIFE, this is at the moment really
on a voluntary basis. I try to take out a lot of time that I could
otherwise spend on additional paying projects, but the day-to-day
follow-up of the mailing list, the web site, the examples, the
release notes, bug fixes, advocacy, and moving the framework forward
really takes up already more time than it should.
You're right that database authentication isn't documented in
detail and it really needs to receive some love since imho it's
*the* area that is the most confusing to people. I think that you
can find what you need here though:
http://thread.gmane.org/gmane.comp.java.rife.user/2767/focus=2767
I read that thread when it came by. It does not answer a single one
of the questions I posed in my blog post.
It does cover in detail the design of the authentication layer and
allows you to understand how it ties in with any customization that
you'd want to make (including the clustered cache question you have
later on). Emmanuel also gives a good summary of how to use database
authentication, with clear code snippets.
Which I'll repeat here with some clarifications so people don't
have to go over there:
What table does the authentication system use for user data, and
what are its columns? (In development mode, it's fine to have the
framework auto-create tables. Not so in production; I want to
control exactly where and how each table is created, make sure I
understand all the integrity constraints, have administrative tools
in place to manipulate the data in a safe way, etc.)
The tables are not 'automatically' created by the framework. It's up
to you to call the install() methods on the manager classes that are
involved. If you want to know the structure, either read the source
code of the manager classes or look at what has been created during
development. You can also set the SQL_DEBUG_TRACE configuration
parameter to 'true' and you'll get a log of all the SQL statements
that are executed.
How does one add or remove a user? (The XML user data gets cached
in memory, so if I just update or insert a database row in the
users table, do I need to notify a cache manager? Is there a way to
disable a user without deleting the row entirely?)
I think you're mixing things here. The memory authentication is
populated from XML. The database authentication isn't cached in
memory, the information comes from the database.
RoleUsersManager (http://rifers.org/docs/api/com/uwyn/rife/
authentication/credentialsmanagers/RoleUsersManager.html) allows you
to manage the users if you use the default credentials manager that
uses RoleUser entities. However, as said in the mailing list thread I
referred to above, you can very easily write a totally custom
CredentialsManager since its mandatory interface is really very
simple (http://rifers.org/docs/api/com/uwyn/rife/authentication/
CredentialsManager.html).
Using RoleUsers, you can easily disable users by using roles and
adding or removing those.
Does the user table have to be completely managed by the
authentication system -- no touching it allowed -- or can it be a
user-supplied table that has data other than login names and
passwords? If so, how does one tell the code to use the alternate
table, and how does one get at the additional data?
If you use the database RoleUsersManagers, you have to use the
structure that it creates or the queries might not work (they might
work in some cases, but that's not really supported behavior).
However as said above, if you want another structure, use your own
manager. You can for example extend the abstract DatabaseUsers class
and provide your own queries.
You can however change the default table names that RIFE uses by
providing other names for the TABLE_ROLE, SEQUENCE_ROLE, TABLE_USER,
TABLE_ROLELINK, TABLE_AUTHENTICATION, TABLE_REMEMBER configuration
parameters.
To store additional data, what I typically do is to create an
AccountManager class and have it manage an 'account' table that
contains all the additional account information and calls the
CredentialsManager when needed.
Is it possible to store session data somewhere other than a
database, e.g. in a clustered cache?
Everything is possible as long as a user is identified my a unique
long number.
Other posts on the mailing list cover this too. You don't really
have to be following the list for a long time, since a simple
search should reveal all the posts that are relevant to you.
I did search and I did not find the answers to my (relatively
common, I believe) questions. But I guess a larger point is that if
I have to search a mailing list archive on a regular basis, it's a
sign of an inadequately-documented system. A mailing list is a very
inefficient reference book -- even if what you want is there, you
have to dig through a lot of noise to get an answer, especially if
it's something that might match a variety of different sets of
keywords.
I totally agree with this, but it's better than nothing at all ;-)
I did reach out to the mailing list a week or so ago to ask for
everyone who receives useful support to take a little bit of time to
properly summarize their question or problem and add it to the wiki
together with the answer or explanation that was provided.
I will pledge to do my part on this and update the Wiki with any
answers I get from the list. I suppose if everyone, or even most
people, did that, the need to search the mailing list would be much
less.
Exactly!
One of the points of the query builders is that the order is not
fixed at all. The real statements are only created when the SQL is
obtained from the builder manually, or when it's executed. This
also means that you can partial query builder objects that you
prepare in one location of your code and complete elsewhere.
Great, that helps. Thanks. I have updated the "Generic query
manager" Wiki page with that information and a couple examples of
specifying multiple query conditions.
Thanks a lot for that.
Hopefully they're accurate; I'm kind of guessing at how the
"whereAnd" method works. (My guess: it acts as a "where" if it's
the first condition, or an "and" if it's not.)
That actually not correct. It's the other way 'round. For
RestoreQuery, "where" acts as "whereAnd" when there are already where
conditions present. However, "whereAnd" always works, since
getRestoreQuery() provides you with a query that has .whereParameter
("[identifiername]", "=") filled in.
I'd like to include an example of mixing "field()" and "where()"
but I'm not really sure what field() does in the context of a
restore query, whose fields are presumably already tied to the
members of a particular class. So I guess that's another question:
what is RestoreQuery.field() for?
I'll direct you to the comments on this issue for an example: http://
uwyn.com/issues/browse/RIFE-282
I hope this information lets you climb out of the dip you're in
and get back up to speed. Otherwise, feel free to mail the list
with any additional questions you have, you'll see that a lot of
people here are very helpful.
Indeed, it's the fact that I've seen most questions answered
helpfully that's one of the most attractive things about RIFE.
Incidentally it's also something that takes up *a lot* of effort and
time. Personally, when having to choose between spending time on
adding missing Javadocs and helpfully answer people on the list in a
timely fashion, I consider the latter more important. This is of
course in the hope that in time people will use their knowledge to
fill in the blanks as a community effort and contribution (which I
and other devs will of course scrutinize and correct when needed).
Take care,
Geert
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
