Hi Pierre,
> > For example: http://rifers.org/docs/api/com/uwyn/rife/authentication/
> > credentialsmanagers/MemoryUsers.html#verifyCredentials
> > (com.uwyn.rife.authentication.Credentials)
>
> In MemoryUsers files, there is no javadocs at all for verifyCredentials.
> So all is fully automatic?
Yes, javadocs of interface methods are copied automatically if you don't
specify any javadocs on those methods in the concrete classes.
> >>> * Defensive markup encoding
> >>
> >> What if is needed some tags as litteral strings, i.e. not to be
> >> interpreted as real tags?
> >
> > You can still encoding them manually using entities like < and >
>
> OK. I don't like it too much but at least it's coherent: if someone need
> a full tag as a litteral, then this person is supposed knowing how to
> preencode it.
>
> Just a last try. What about:
> - regexp to detect tag to use as it is
> - but only if no escaping at the beginning of the whole tag
I still don't like it ;-) You're introducing an artificial way of
escaping, while HTML encoding can easily be used. We try to leverage as
much of possible of the existing standards. So when someone knows how to
use entities for HTML encoding, they're set. Also the other way 'round,
when people know how to encode for in the properties files, they'll find
out that they can leverage this knowledge in other situations too.
> >>> * The I18n class
> >>>
> >>> This seems to be too hardcoded and linked to a SpringWeb
> >>> participant. I don't like this very much since Spring should
> >>> merely be a one possible IoC reference factory.
> >>
> >> I put all the Spring dependencies into I18n class. Then it should be
> >> the only part to refactor if an other container is to be used.
> >
> > Yes, but you reference the I18n class in the engine package, which
> > means that there's a hard dependency on it and thus on Spring.
>
> OK. But in my first proposition about only locales, there was already
> such a dependency (I18n.java was then Locales.java). I don't see why
> here it more an issue.
I didn't read that proposal in as much detail as now, that's why I
probably didn't spot it at first.
> > There's not injection of the actual locale-related class instances.
>
> I'm not sure what is the point here. The getLocaleProviderFactory and
> getLocaleProvider from the initial Locales class are still present in
> the I18n one.
The code that creates a problem is this:
if (Rep.hasParticipant(SPRING_WEB)) {
for(Participant participant : Rep.getParticipants(SPRING_WEB)) {
You tie the L18n class to that particular participant, this should be
more flexible.
Best regards,
Geert
_______________________________________________
Rife-users mailing list
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
