Sorry, forgot in what's remaining :
5. Modify @ViewAction
Per default, @ViewAction("#{myController.handle()}") is called before
RENDER_RESPONSE.
You can change this by using @Before/After with another jsf phase (i.e.
@ApplyRequestValues).
You get sthing like :
@UrlMapping(pattern = "/item/#{id}/")
@ViewPattern("/item.xhtml")
@ViewController(PageController.class)
@Owner
@ViewAction("#{pageController.viewAction(pageController.item)}")
@Before @ApplyRequestValues
ITEM
Not really happy here, because :
a. link between ViewAction annotation and Before / ApplyRequestValues is not
straighforward.
b. if someone develops another extension relying on the same annotations
(Before, etc...) we can have a conflict.
Wouldn't it be better if we introduced before and phase attributes into
@ViewAction ?
The cons of it is that it won't be symetric with @ViewActionBindingType and
@ViewController which rely on Before / ApplyRequestValues annotations.
Sorry for the rather long topic..
----- Mail original -----
De : Adrian Gonzalez <[email protected]>
À : "[email protected]" <[email protected]>
Cc :
Envoyé le : Mercredi 2 Novembre 2011 20h59
Objet : [seam-dev] Re : Re : Re : Re : SEAMFACES-147 viewActions
Hello,
First preview is available here
: https://github.com/gonzalad/faces/tree/SEAMFACES-147
The 3 approaches @ViewActionBindingType, @ViewController and @ViewAction are
implemented.
I've included a basic sample in viewconfig webapp.
Java source
: https://github.com/gonzalad/faces/tree/SEAMFACES-147/examples/viewconfig/src/main/java/org/jboss/seam/faces/examples/viewconfig
JSF pages
: https://github.com/gonzalad/faces/tree/SEAMFACES-147/examples/viewconfig/src/main/webapp
What's remaining :
1. order between restrict actions and view pages actions.
I'm quite stuck here : CDI events aren't ordered, and both kind of action
use the JSF/CDI bridge based on CDI events.
2 options come to my mind :
* go back to basic JSF phase listeners.
* Modify SecurityPhaseListener to propagate the original event with one
qualifier more on success (@AfterRestriction for instance) - don't like this,
because SecurityPhaseListener is optionnal (depends on presence of
seam-security).
2. [optional] introduce a @BeforeAction annotation
This annotation would be called before a JSF action (whether immediate or
not).
WDYT ? Is it necessary ? If not, I don't introduce it (the less, the better).
3. create some unit test.
Don't know where to start, there's no unit test for restrictions (for my
inspiration).
4. Refactor
a. Don't like dependency from *Store to *Extension (should be the other way
around).
b. ViewConfigStoreImpl could perhaps use Qualifier / Annotation algorithm
from ViewConfigDescriptor (my fault : I've duplicated them).
----- Mail original -----
De : Adrian Gonzalez <[email protected]>
À : "[email protected]" <[email protected]>
Cc :
Envoyé le : Lundi 31 Octobre 2011 19h59
Objet : [seam-dev] Re : Re : Re : SEAMFACES-147 viewActions
Hello,
An update on this one and 2 more questions (oups....;) )
I've a really first draft for View Controllers (similar to CODI).
I can now do this (@ViewController annotation) :
@ViewConfig
public interface MyAppViewConfig {
@UrlMapping(pattern = "/item/#{id}/")
@ViewPattern("/item.xhtml")
@ViewController(PageController.class)
@Owner
ITEM
}
With PageController :
@ViewScoped
@Named
public class PageController implements Serializable {
@BeforeRenderView
public void loadEntry(@Current Item item) {
System.out.println("loadEntry called "+item);
}
}
WDYT ?
So here are my questions :
1. I would like to use @RenderResponseand @Before annotations here, but I
cannot for the moment since they don't target METHOD type.
Could we add METHOD target for those annotations ?
2. I've needed to convert a java.lang.reflect.Method to AnnotatedMethod.
Could you confirm that it's possible by doing this :
AnnotatedType annotatedType =
beanManager.createAnnotatedType(method.getDeclaringClass());
Set<AnnotatedMethod> annotatedMethods = annotatedType.getMethods();
AnnotatedMethod annotatedMethod = null;
for (AnnotatedMethod current : annotatedMethods) {
if (current.getJavaMember().equals(method)) {
annotatedMethod = current;
}
}
Thanks !
________________________________
De : Adrian Gonzalez <[email protected]>
À : Jason Porter <[email protected]>
Cc : "[email protected]" <[email protected]>
Envoyé le : Samedi 29 Octobre 2011 17h31
Objet : [seam-dev] Re : Re : SEAMFACES-147 viewActions
Thanks for the update
I'm enjoying my weekend - no developement - so no need to hurry ;)
Also, I was wondering if it wouldn't be nice to add some Page or Controller
notion to viewActions (similar to CODI PageBean notion
: https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-PageBeans).
The end used would be able to choose between 3 possible use case :
1. Untyped approach (not so CDI like - but dead simple)
@ViewConfig
public interface ApplicationViewConfig {
static enum View1 {
@ViewPattern("/item.xhtml")
@ViewAction("#{bean.doSomething()}")
VIEW_ITEM;
}
}
2. Typed
@ViewConfig
public interface ApplicationViewConfig {
static enum View1 {
@ViewPattern("/item.xhtml")
VIEW_ITEM;
}
}
public class ItemAction {
@ViewAction(VIEW_ITEM)
public void loadItem() {
...
}
}
3. Page Controller
@ViewConfig
public interface ApplicationViewConfig {
static enum View1 {
@ViewPattern("/item.xhtml")
@Controller(ItemController.class)
VIEW_ITEM;
}
}
public class ItemController {
@BeforePhase(RENDER_RESPONSE)
public void loadItem() {
...
}
}
________________________________
De : Jason Porter <[email protected]>
À : Adrian Gonzalez <[email protected]>
Cc : "[email protected]" <[email protected]>
Envoyé le : Samedi 29 Octobre 2011 4h02
Objet : Re: [seam-dev] Re : SEAMFACES-147 viewActions
I think Brian is planning on issuing an in depth response in a day or two.
Thanks for your help!
On Thu, Oct 27, 2011 at 10:00, Adrian Gonzalez <[email protected]> wrote:
Additionnal thoughts :
>
>As I understand ViewConfigStore for now, any extension can use ViewConfigStore
>to store about any metadata (event if it's limited to Annotation for the
>moment).
>So this is great for additionnal features.
>
>If we go for solution 4, Page/View will be typed and future extensions will be
>limited.
>We can however add a metadatas field in Page/View for extensions to store
>about anything in a view.
>
>IMO, solution 4 would make the code easier to understand (more typed) - but
>breaks a lot of code, and since I'm a newbie here...
>
>
>
>________________________________
>De : Adrian Gonzalez <[email protected]>
>À : "[email protected]" <[email protected]>
>Envoyé le : Jeudi 27 Octobre 2011 17h44
>Objet : [seam-dev] SEAMFACES-147 viewActions
>
>
>Hello,
>
>I'm working a bit on this issue.
>
>But I'm stuck now and would like to know the better way to continue (sorry to
>bother once more ;( ).
>
>For the moment I've :
>1. registered all viewActionBindings into the viewConfigStore.
>2. more or less replicated SecurityPhaseListener functionnality into
>a ViewActionPhaseListener.
>
>But... viewConfigStore can only store Annotations. I need to store
>AnnotatedMethod (have a link back to the Method I'll need to call).
>
>I see 4 possible solutions :
>
> 1 - Duplicate ViewConfigStoreImpl to store AnnotatedMethod elements.
> Ugly, no ?
> 2 - Make ViewConfigStore manage all kind of AnnotatedElements with a wrapper
>interface like
>interface AnnotatedElement<T> {
>Annotation<T> annotation;
>Object value;
>}
>ViewConfigStore :
>public interface ViewConfigStore {
>public abstract void addAnnotationData(String viewId, AnnotatedElement
>annotation);
>public abstract AnnotatedElement<T> T getAnnotationData(String viewId,
>Class<T> type);
>public abstract List<AnnotatedElement<T>> getAllAnnotationData(String viewId,
>Class<T> type);
>public abstract List<AnnotatedElement> getAllQualifierData(String viewId,
>Class<? extends Annotation> qualifier);
>public <T extends Annotation> Map<String, Annotation>
>getAllAnnotationViewMap(Class<T> type);
>}
>3 - ViewConfigStore could store Annotated elements instead of Annotations
> This would make ViewConfigStore usage a little more complicated though.
>4 - Have somes typed Page or View objects.
> This need really more reflection since we need to know what is a View
>(security, view actions, ...).
>And it's a big impact on current code.
>The ViewConfigStore would be sthing like (really incomplete) :
>ViewConfigStore :
>public Map<String,ViewInfo> getView(String viewId);
>public List<View> getViews();
>}
>with for instance :
>class/interface View {
>List<Restriction> getRestrictions();
>List<ViewAction> getViewActions(); //or event List<Action> getAction(PhaseId)
>}
>
>WDYT ?
>
>P.S. Sorry for the rather long mail........
>
>
>More details on what I have done for now :
>
>As noted in the ticket, I can now create a viewAction annotation like this one
>:
>
>
>@ViewActionBindingType
>@Retention(RetentionPolicy.RUNTIME)
>@Target({ElementType.FIELD, ElementType.METHOD, ElementType.TYPE})
>public @interface MyViewAction {
>MyAppViewConfig.Pages value();
>}
>
>MyAppViewConfig being the sample @ViewConfig annotated class in viewconfig
>sample.
>
>I can then use MyViewAction like this :
>
>
>@ViewScoped
>@Named
>public class PageController implements Serializable {
> @MyViewAction(Pages.ITEM)
> public void loadEntry() {
> System.out.println("loadEntry called");
> }
>}
>
>For the moment, my code doesn't call this method (I'll just need to copy Seam
>Security code for it ;) ).
>
>
>I've also created the following annotation that you can use to annotate your
>own viewAction annotation :
> - @Condition(condition=String) -> not really type safe.....
> - @Immediate(immediate=Boolean)
> - @OnPostback(onPostback=boolean)
> - @Phase(value=PhaseIdType)
>
>Also, if you need to customise those behaviour per-usage, you can add
>attributes into your viewAction annotation :
>@MyViewAction(Pages.ITEM, immediate=true, condition="#{myBean.eager}")
>public void loadEntry()
>
>_______________________________________________
>seam-dev mailing list
>[email protected]
>https://lists.jboss.org/mailman/listinfo/seam-dev
>
>_______________________________________________
>seam-dev mailing list
>[email protected]
>https://lists.jboss.org/mailman/listinfo/seam-dev
>
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
_______________________________________________
seam-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
seam-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
seam-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
seam-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/seam-dev
