Showing posts with label myfaces codi. Show all posts
Showing posts with label myfaces codi. Show all posts
Thursday, November 8, 2012
Friday, May 11, 2012
Monday, February 6, 2012
Wednesday, December 7, 2011
deltaspike joins the asf incubator
the vote to join the incubator was closed. there were 8 binding +1 votes, 3 non-binding +1 votes and no -1 votes. in parallel several other folks showed up and told us that they are interested to join the effort.
Wednesday, November 30, 2011
deltaspike - the future of myfaces codi (is bright)
today we announced the future of myfaces codi.
that means: codi goes apache tlp (top level project) together with others (esp. the seam3 team and the cdi-source team). as mentioned in the announcement: we will continue with codi. several features will be promoted to deltaspike and codi v2 will be based on deltaspike and will provide all features which won't be available in deltaspike itself. codi v1 will continue (it will be improved and maintained as it is and won't migrate to deltaspike).
that means: codi goes apache tlp (top level project) together with others (esp. the seam3 team and the cdi-source team). as mentioned in the announcement: we will continue with codi. several features will be promoted to deltaspike and codi v2 will be based on deltaspike and will provide all features which won't be available in deltaspike itself. codi v1 will continue (it will be improved and maintained as it is and won't migrate to deltaspike).
Saturday, August 27, 2011
[myfaces] setup of codi and extval
in the last weeks i saw a lot of users looking for information about setting up and/or configuring extval and/or codi.
the simple answer: both don't required configuration by default.
zero config allows you to add the jar files you would like to use to your project and that's it.
(in case of codi you have to ensure that you have configured the cdi implementation of your choice correctly. in case of the bv module of extval, you have to ensure that you added the bv implementation of your choice.)
information about the libs is available in the corresponding wiki which is liked on the official website of each project. please check the wiki and/or send a mail to the mailing list.
the simple answer: both don't required configuration by default.
zero config allows you to add the jar files you would like to use to your project and that's it.
(in case of codi you have to ensure that you have configured the cdi implementation of your choice correctly. in case of the bv module of extval, you have to ensure that you added the bv implementation of your choice.)
information about the libs is available in the corresponding wiki which is liked on the official website of each project. please check the wiki and/or send a mail to the mailing list.
Tuesday, June 21, 2011
codi meets jboss as 7
since jboss application server v7 (jboss as 7) is short before the beta 4 and rc1 release, i tested the latest head with the latest version of codi. as tweeted, everything worked well. all workarounds for mojarra and weld we had to use for glassfish v3 also work on as7.
Wednesday, June 1, 2011
session based view-scope with codi
codi itself offers an adapter for the view-scope of jsf2+ as well as a view-access scope which sounds similar but is something completely different (there is a 2nd blog entry about the difference). this entry is not about the view-access scope. it's about the view-scope which was introduced by jsf2. the adapter provided by codi allows you to bind cdi beans to the view-scope of jsf2+ directly. that's the reason why it's only available for jsf2+ whereas the other scopes of codi can be used with jsf1.2 as well as jsf2+. however, besides the basic concept of the view-scope, the default implementation has also some disadvantages (like losing the state in case of a browser-refresh, if there is no form with input components). if you haven't faced such issues, you might skip this blog entry. as mentioned before there is no standard way for jsf1.2 users to use the view-scope of jsf2+.
after several questions about it i decided to implement a codi-add-on which can be used with jsf1.2 as well as with jsf2+. due to the powerful spi of codi, the result is a simple implementation which offers additional features like grouped beans (you can manually destroy beans of the same group immediately even though you stay on the same page), optional bean events,... .
it's e.g. problematic for some use-cases that the jsf2+ implementation of the view-scope stores the beans in the component tree. so several users ask for a session based view-scope. that means the beans for a page will be stored in the session instead of the component tree. if you really need such a scope instead of the view-access-scope provided by codi, you can implement such a scope with the spi of codi + two simple classes.
approach #1
the first one is a marker annotation and the second one an observer for the PreViewConfigNavigateEvent. that's it! if you only use the type-safe navigation of codi, you are done and you annotate your bean with @View and the @ConversationScoped annotation provided by codi. as soon as a navigation to a new page is detected all conversation scoped beans annotated with @View will be destroyed.
if you don't use the type-safe navigation of codi, you can implement e.g. a custom jsf navigation handler which does the same for all navigations.
if you prefer a single annotation instead (let's call it @MyViewScoped), you can write a portable cdi extension which adds the @ConversationScoped dynamically to all beans which are annotated with @MyViewScoped.
it took longer to write this blog entry, than implementing this mechanism :)
or
approach #2
the result of this approach is the same like approach #1. the advantage is that you don't have to care about the navigation and the disadvantage is that you have to extend a default implementation.
if you are ok with extending the default implementation (with weld you have to #veto the default implementation instead of using @Specializes), you can override the default implementation of #createConversation (a method which is part of the spi of codi). if you just implement the interface, you would override everything and you would deactivate all codi scopes. ok - so let's add a new scope with the same marker annotation and a ConversationFactory instead of the observer:
this implementation is compatible with all jsf concepts which are supported by codi!
approach #2.1
this approach is the same like #2 but instead of implementing it on our own, we can just use the @ViewConversationScoped provided by the enhanced-conversations add-on for codi:
after several questions about it i decided to implement a codi-add-on which can be used with jsf1.2 as well as with jsf2+. due to the powerful spi of codi, the result is a simple implementation which offers additional features like grouped beans (you can manually destroy beans of the same group immediately even though you stay on the same page), optional bean events,... .
it's e.g. problematic for some use-cases that the jsf2+ implementation of the view-scope stores the beans in the component tree. so several users ask for a session based view-scope. that means the beans for a page will be stored in the session instead of the component tree. if you really need such a scope instead of the view-access-scope provided by codi, you can implement such a scope with the spi of codi + two simple classes.
approach #1
the first one is a marker annotation and the second one an observer for the PreViewConfigNavigateEvent. that's it! if you only use the type-safe navigation of codi, you are done and you annotate your bean with @View and the @ConversationScoped annotation provided by codi. as soon as a navigation to a new page is detected all conversation scoped beans annotated with @View will be destroyed.
if you don't use the type-safe navigation of codi, you can implement e.g. a custom jsf navigation handler which does the same for all navigations.
if you prefer a single annotation instead (let's call it @MyViewScoped), you can write a portable cdi extension which adds the @ConversationScoped dynamically to all beans which are annotated with @MyViewScoped.
it took longer to write this blog entry, than implementing this mechanism :)
or
approach #2
the result of this approach is the same like approach #1. the advantage is that you don't have to care about the navigation and the disadvantage is that you have to extend a default implementation.
if you are ok with extending the default implementation (with weld you have to #veto the default implementation instead of using @Specializes), you can override the default implementation of #createConversation (a method which is part of the spi of codi). if you just implement the interface, you would override everything and you would deactivate all codi scopes. ok - so let's add a new scope with the same marker annotation and a ConversationFactory instead of the observer:
this implementation is compatible with all jsf concepts which are supported by codi!
approach #2.1
this approach is the same like #2 but instead of implementing it on our own, we can just use the @ViewConversationScoped provided by the enhanced-conversations add-on for codi:
Friday, April 15, 2011
Saturday, February 26, 2011
codi examples with myfaces stylesheet
there are several examples for myfaces codi in the myfaces-repository. most of them are just dev examples esp. for an easier communication between members of the dev team. users might be confused because they don't know the intention of the details. therefore, i started with the first hello-world example which will be shipped with the next release. currently the example shows some simple use-cases. you will see further examples in the near future. all examples (which are available in the myfaces-repository) with the official myfaces-stylesheet might be interesting for users.
screenshot of the first example:
screenshot of the first example:
Thursday, November 11, 2010
[infra] myfaces extensions meet dvcs
it's getting easier for the community to contribute to myfaces-extensions *!
now we have official git mirrors:
and
as well as inofficial mercurial mirrors (hg isn't supported by the asf):
and
in case of myfaces-extensions * the mercurial repositories provide an additional feature. early adaptors can request an inofficial (external) milestone at any time. it's easier to handle issues compared to nightly builds.
dvcs like mercurial and git allow easy forking of repositories and experimenting with new features. with features like squash it's very easy to donate the result of your feature-branch!
so let's get started: fork -> experiment -> donate (your patch)!
Friday, September 24, 2010
[javaone] myfaces extval and myfaces codi meet j1 2010
that's nice! matthias and ali presented myfaces at j1 2010. one part of the presentation was myfaces extval (e.g. [1] [2]) and a second part was about myfaces codi (e.g. [1] [2]). it was the first preview of myfaces codi at a java conference.
Thursday, September 23, 2010
[preview] codi meets cwiki.apache.org
it's really nice. myfaces codi as well as the documentation for it is still in progress and i see a lot of positive response out there.
some days ago i started with the documentation (it's still in progress) and google analytics shows that people are already reading it!
some days ago i started with the documentation (it's still in progress) and google analytics shows that people are already reading it!
Subscribe to:
Posts (Atom)