due to a valid user request (a possible combination with spring security) also the functionality of the extval app-prototyping add-on (and more) will be available in the next release. early adaptors can use the current svn version or the next milestone (m2) which will be available soon.
the add-on won't be obsolete. there will be new functionality!
Thursday, July 30, 2009
Wednesday, July 29, 2009
myfaces extval @ jsfcentral
the next part of the article series is available at jsfcentral.
thx to the jsfcentral team!
thx to the jsfcentral team!
Tuesday, July 21, 2009
myfaces-extval and pattern based validation
i saw that people search quite often for an example which shows pattern/regex based validation.
it's quite easy. just use @Pattern and use the regex as value (as expected).
a short example is:
@Pattern("[A-Z][a-z]+")
the examples shipped with every extval release shows the usage as well.
or you can check out the examples from the repository.
it's quite easy. just use @Pattern and use the regex as value (as expected).
a short example is:
@Pattern("[A-Z][a-z]+")
the examples shipped with every extval release shows the usage as well.
or you can check out the examples from the repository.
Saturday, July 18, 2009
myfaces extval and richfaces - 2
i started a special support module for richfaces.
currently it contains an addition to support labeled faces messages for the rich:calendar component.
currently it contains an addition to support labeled faces messages for the rich:calendar component.
Labels:
jsf,
myfaces-extensions,
myfaces-extval,
richfaces,
sev-en
myfaces-extval and icefaces - 2
this is an update of the original post:
1)
extval and icefaces uses similar approaches to implement an internal mechanism. with mojarra there is no issue (by chance). in combination with myfaces-core there was an issue which is fixed with the following combination: icefaces 1.8.2 (see ) and an icefaces support module.
2)
internally icefaces components use some jsf 1.1 mechanisms. that's the reason why you have to use the described fallback. that will change with icefaces 2.0 (which will be compatible with jsf 1.2).
if you are using the support module + the current extval-snapshot + the upcoming version of icefaces (1.8.2 - or a pached version of 1.8.1), you don't have to follow the instructions of the original post. you just have to add the dependencies and everything will work as expected.
a very simple example is available here
1)
extval and icefaces uses similar approaches to implement an internal mechanism. with mojarra there is no issue (by chance). in combination with myfaces-core there was an issue which is fixed with the following combination: icefaces 1.8.2 (see ) and an icefaces support module.
2)
internally icefaces components use some jsf 1.1 mechanisms. that's the reason why you have to use the described fallback. that will change with icefaces 2.0 (which will be compatible with jsf 1.2).
if you are using the support module + the current extval-snapshot + the upcoming version of icefaces (1.8.2 - or a pached version of 1.8.1), you don't have to follow the instructions of the original post. you just have to add the dependencies and everything will work as expected.
a very simple example is available here
Labels:
icefaces,
jsf,
myfaces-extensions,
myfaces-extval,
sev-en
myfaces extval - new snapshot available
early adaptors can use the current snapshot!
it includes some minor internal changes as well as EXTVAL-49 - EXTVAL-53.
furthermore, it's the version used for component-support/icefaces-support
it includes some minor internal changes as well as EXTVAL-49 - EXTVAL-53.
furthermore, it's the version used for component-support/icefaces-support
Labels:
jsf,
myfaces-extensions,
myfaces-extval,
sev-en,
snapshot
Wednesday, July 15, 2009
os890 thanks for the great interest
it's amazing. today i had a look at the google analytics statistics.
since the first announcement of myfaces extval a lot people evaluated the framework, provided ideas for add-ons and new features, sent several e-mails about the great experience while using extval and much more.
half a year ago we saw the first release of extval.
now i can report some nice numbers of os890:
~4000 visitors
~12000 page views
and visitors of 88 countries
furthermore, within 5 months there were over 900 downloads of the introduction slides.
these numbers don't include the statistics of the wiki pages hosted at apache directly.
since the first announcement of myfaces extval a lot people evaluated the framework, provided ideas for add-ons and new features, sent several e-mails about the great experience while using extval and much more.
half a year ago we saw the first release of extval.
now i can report some nice numbers of os890:
~4000 visitors
~12000 page views
and visitors of 88 countries
furthermore, within 5 months there were over 900 downloads of the introduction slides.
these numbers don't include the statistics of the wiki pages hosted at apache directly.
your custom cross-validation
if you have a bunch of cross-validation strategies, please have a look at EXTVAL-53!
in case of objections, please send a veto to undo the change.
so far there wasn't a major change which affects custom implementations. this is the first one. we did it to stay consistent internally and because it is very easy to migrate with a simple search/replace action which is safe.
if you just used the annotations, you won't notice a change. you just notice it at custom cross-validation implementations. normally there aren't tones of it, so it isn't a big issue. nevertheless backward compatibility is basically important for us. since it's an important change for some of you, everybody is allowed to veto.
details are available the description of the issue.
in case of objections, please send a veto to undo the change.
so far there wasn't a major change which affects custom implementations. this is the first one. we did it to stay consistent internally and because it is very easy to migrate with a simple search/replace action which is safe.
if you just used the annotations, you won't notice a change. you just notice it at custom cross-validation implementations. normally there aren't tones of it, so it isn't a big issue. nevertheless backward compatibility is basically important for us. since it's an important change for some of you, everybody is allowed to veto.
details are available the description of the issue.
Friday, July 10, 2009
Wednesday, July 8, 2009
myfaces extval snapshots
several people asked for a new version via a public maven repository.
in fact the current snapshot contains some great new features. so extval for jsf 1.2.x is now available in the snapshot repository!
(the next release of extval depends e.g. on the final release of jsr303 - so i plan stable snapshots for important milestones. feel free to use the latest snapshot!)
in fact the current snapshot contains some great new features. so extval for jsf 1.2.x is now available in the snapshot repository!
(the next release of extval depends e.g. on the final release of jsr303 - so i plan stable snapshots for important milestones. feel free to use the latest snapshot!)
Monday, July 6, 2009
myfaces extval and richfaces
so far this combination worked when using myfaces-core.
extval-38 (as well as the wiki) shows the required dependencies.
the mentioned issue describes that there is an issue with mojarra.
the good news: the issue is fixed and you can use this combination.
i hope a lot of you (who signaled interest in this combination) will start to test the new version or a patched version of v1.2.2 you can find here.
some details about the original issue:
the generic support module is required, if a component lib does special things behind the scenes.
e.g.: casting renderers,...
so the module uses cglib to allow that. via an extval startup listener the module installs itself. the issue with mojarra is that it uses early configuration. so the extval startup listener of the module gets invoked too late and important configuration tasks are performed by an extval-core class instead of the lazily installed class of the generic support module.
extval-38 (as well as the wiki) shows the required dependencies.
the mentioned issue describes that there is an issue with mojarra.
the good news: the issue is fixed and you can use this combination.
i hope a lot of you (who signaled interest in this combination) will start to test the new version or a patched version of v1.2.2 you can find here.
some details about the original issue:
the generic support module is required, if a component lib does special things behind the scenes.
e.g.: casting renderers,...
so the module uses cglib to allow that. via an extval startup listener the module installs itself. the issue with mojarra is that it uses early configuration. so the extval startup listener of the module gets invoked too late and important configuration tasks are performed by an extval-core class instead of the lazily installed class of the generic support module.
Labels:
jsf,
myfaces-extensions,
myfaces-extval,
richfaces,
sev-en
Subscribe to:
Posts (Atom)