Hi Pierre,
welcome!
Feel free to ask any questions you have, we're here to help. :-)
I haven't thought of using aspects for this, it could be an
interesting idea. However, I'm not sure it's appropriate for this use-
case. There is no real cross-concerns logic to be added. Constraints
are always mapped to the POJO that they describe. So I suspect that
extracting this into an aspect-oriented approach would complicate
things needlessly. I have very little AOP experience though, so I
might be wrong.
Best regards,
Geert
On 30-okt-05, at 18:31, Pierre Raoul wrote:
Hello,
I'm a newcomer who try to run the examples (atm I'm stuck with
chapter 8; may be my next email ;-) ), but may I suggest :
- to keep an option with Rife as it is,
- to add an option "Rife with AOP", and use for example Spring
capabilities or even AspectJ
Regards
Pierre
Geert Bevin a écrit :
As I said to Keith, this would be an additional way of specifying
the constraints.
The main reasons are:
* allow for migration of existing POJOs models towards RIFE
(Spring, Hibernate, ...)
* create POJOs in a RIFE application that are framework-
independent and can be used together with other solutions
I you look how this would be practically, it doesn't change much
imho.
Let's compare:
Traditional method
==================
public class Blog extends CmfValidation
{
private int mId = -1;
private Date mMoment = Calendar.getInstance().getTime();
private byte[] mImage = null;
private String mTitle = null;
private String mBody = null;
private boolean mDraft = false;
protected void activateValidation()
{
addConstraint(new ConstrainedBean()
.defaultOrder("moment", ConstrainedBean.DESC)
.defaultOrder("title"));
addConstraint(new CmfProperty("id")
.editable(false)
.identifier(true));
addConstraint(new CmfProperty("moment")
.listed(true)
.notNull(true));
addConstraint(new CmfProperty("image")
.listed(true)
.mimeType(MimeType.IMAGE_PNG)
.contentAttribute("width", 150)
.notNull(true)
.file(true));
addConstraint(new CmfProperty("title")
.listed(true)
.notNull(true)
.notEmpty(true)
.maxLength(100));
addConstraint(new CmfProperty("body")
.mimeType(MimeType.APPLICATION_XHTML)
.autoRetrieved(true)
.fragment(true)
.notNull(true)
.notEmpty(true));
addConstraint(new CmfProperty("draft")
.notNull(true)
.defaultValue(false));
}
// accessors omitted
}
True POJO method
================
public class Blog extends CmfValidation
{
private int mId = -1;
private Date mMoment = Calendar.getInstance().getTime();
private byte[] mImage = null;
private String mTitle = null;
private String mBody = null;
private boolean mDraft = false;
// accessors omitted
}
public class BlogMetaData extends CmfValidation
{
protected void activateValidation()
{
addConstraint(new ConstrainedBean()
.defaultOrder("moment", ConstrainedBean.DESC)
.defaultOrder("title"));
addConstraint(new CmfProperty("id")
.editable(false)
.identifier(true));
addConstraint(new CmfProperty("moment")
.listed(true)
.notNull(true));
addConstraint(new CmfProperty("image")
.listed(true)
.mimeType(MimeType.IMAGE_PNG)
.contentAttribute("width", 150)
.notNull(true)
.file(true));
addConstraint(new CmfProperty("title")
.listed(true)
.notNull(true)
.notEmpty(true)
.maxLength(100));
addConstraint(new CmfProperty("body")
.mimeType(MimeType.APPLICATION_XHTML)
.autoRetrieved(true)
.fragment(true)
.notNull(true)
.notEmpty(true));
addConstraint(new CmfProperty("draft")
.notNull(true)
.defaultValue(false));
}
}
On 30-okt-05, at 17:50, Stefan wrote:
Indeed, splitting this information into too many classes may
result in confusion instead of ease of use. Why not do something
like WindowListener and WindowAdapter in java? So having a
default class if interface implementation is not simple enough?
Or maybe a Wrapper/Delegator could be added.
Also, seeing the current way annotations are used in java (EJB
3.0 for example) currently anyone tries not to spread too much
information in different files.
Keith Lea schrieb:
I think requiring 2 classes for each bean sucks. I know it
won't be required, but I think even allowing you to do it this
way is encouraging complicated, verbose, hard to maintain code.
On Oct 30, 2005, at 3:47 AM, Geert Bevin wrote:
Hi everyone,
currently, the persistence engine requires your POJOs to
implement the Constrained and Validated interface, which can
be quite a burden if you don't extend the CmfValidation or
Validation base classes. I was thus thinking of adding
support for declaring all the meta-data in an external
parallel class.
So if your POJO is named like this:
com.mypakkage.ThisPojo
RIFE would look for:
com.mypakkage.ThisPojoMetaData
If this class exists and implements the required interface, it
will be instantiated for each instance of ThisPojo that is
inspected for meta-data.
Sadly this is not as simple as it sounds, since RIFE's
validation is state-full. It has been designed to stick
around as a collector for all validation errors that can
appear in any possible layer, until the errors are explicitly
cleared. To make this possible, I should add a registry
(WeakHashMap) that keeps track of each ThisPojo instance and
the associated ThisPojoMetaData instance.
The most logical location to add this would be an additional
Participant. However, since this is such a fundamental core
feature, it seems awkward to require everybody to add this
participant explicitly. It would this always be added by
default to the standard Repository implementation (maybe even
to the custom ones). Another option would be to just have a
static map in ConstrainedUtils, but that feels very dirty.
What do you think of all this? Do you think it is worth the
effort? Any better ideas to preserve the instance and meta-
data mapping?
Thanks for you input,
Geert
--
Geert Bevin Uwyn bvba
"Use what you need" Avenue de Scailmont 34
http://www.uwyn.com 7170 Manage, Belgium
gbevin[remove] at uwyn dot com Tel +32 64 84 80 03
PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F
D6A9
Public PGP key : available at servers pgp.mit.edu,
wwwkeys.pgp.net
_______________________________________________
Rife-users mailing list
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
_______________________________________________
Rife-users mailing list
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
_______________________________________________
Rife-users mailing list
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
--
Geert Bevin Uwyn bvba
"Use what you need" Avenue de Scailmont 34
http://www.uwyn.com 7170 Manage, Belgium
gbevin[remove] at uwyn dot com Tel +32 64 84 80 03
PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net
_______________________________________________
Rife-users mailing list
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
_______________________________________________
Rife-users mailing list
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
--
Geert Bevin Uwyn bvba
"Use what you need" Avenue de Scailmont 34
http://www.uwyn.com 7170 Manage, Belgium
gbevin[remove] at uwyn dot com Tel +32 64 84 80 03
PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net
_______________________________________________
Rife-users mailing list
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
