On Wed, Mar 23, 2011 at 3:02 PM, Marek Śmigielski <marek.smigielski(a)gmail.com&gt; wrote: > > Hi, > > In last few day I have deeply thought over wicket modul features > essential to fully integrate with wicket framework. In wicket > architecture there is idea of model as a state bean. Its quite > different in terms of live cycle from scopes provided by CDI. > > 1. It is page scope (in some cirumstances more than one http request) > 2. It is serialized after each request and store in session or disk. > > Wicket modules misses integration throught model object with wicket > architecture so I've developed some integration with it. The idea is > that you can achieve CDI beans exactly in the same way like in JSF, > through expressionLanguage. So you can inject any named or other el > bean via: > >   @Inject @ModelExpression("#{nameBean}") >   private SeamModel<String> label; > > and later use it on your page directly: > > Label label = new Label("headerLabel", headerLabelModel); > > or wrap it by other wicket model: > >   @Inject @ModelExpression("#{registartion}") >   private SeamModel<Registartion> registartion; > > > Form registrationForm = new Form("registartionForm", new > CompoundPropertyModel(registartion)); > > and later use it on whole form. > I'm not sure what benefit this provides.  The wicket page instance is already a scope, if you wanted something specific to the page, you could just add it as a field to the page or component.  And EL as a referencing mechanism is a little too JSF-esque (weakly bound, not refactoring safe) to be well suited to a wicket integration layer.

> > As I follow seam 3 for some time now I understand that this is time > for bugfix rather than adding new features. Is it possible to merge > this code before final realese? > > Second feature is rather small and not soo excited as previous one. > I've prepared possiblity to inject ResourceStreamLocator. Deafault is > exactly the same as in wicket but I had also developed alternative > one, which enables throught configuration to change the place where > html file are stored. In my opinion it's also simplification. >  Wicket already has a way to register resource stream locators, I don't see why we need a yet another way to do it.  Can you elaborate?

-Clint

On 23 Mar 2011, at 21:55, Marek Śmigielski wrote: > On Wed, Mar 23, 2011 at 9:54 PM, Clint Popetz <cpopetz(a)gmail.com&gt; wrote: >> >> >> On Wed, Mar 23, 2011 at 3:02 PM, Marek Śmigielski >> <marek.smigielski(a)gmail.com&gt; wrote: >>> >>> Hi, >>> >>> In last few day I have deeply thought over wicket modul features >>> essential to fully integrate with wicket framework. In wicket >>> architecture there is idea of model as a state bean. Its quite >>> different in terms of live cycle from scopes provided by CDI. >>> >>> 1. It is page scope (in some cirumstances more than one http request) >>> 2. It is serialized after each request and store in session or disk. >>> >>> Wicket modules misses integration throught model object with wicket >>> architecture so I've developed some integration with it. The idea is >>> that you can achieve CDI beans exactly in the same way like in JSF, >>> through expressionLanguage. So you can inject any named or other el >>> bean via: >>> >>>   @Inject @ModelExpression("#{nameBean}") >>>   private SeamModel<String> label; >>> >>> and later use it on your page directly: >>> >>> Label label = new Label("headerLabel", headerLabelModel); >>> >>> or wrap it by other wicket model: >>> >>>   @Inject @ModelExpression("#{registartion}") >>>   private SeamModel<Registartion> registartion; >>> >>> >>> Form registrationForm = new Form("registartionForm", new >>> CompoundPropertyModel(registartion)); >>> >>> and later use it on whole form. >>> >> >> I'm not sure what benefit this provides.  The wicket page instance is >> already a scope, if you wanted something specific to the page, you could >> just add it as a field to the page or component.  And EL as a referencing >> mechanism is a little too JSF-esque (weakly bound, not refactoring safe) to >> be well suited to a wicket integration layer. > I think that it's worth to have some way of injection components > straight to wicket model beans. Duplication of the fields between > wicket page and request component (or any scope component) in my > opinion is unnecessary. I agree that EL and wicket concept don't fit > well, but I haven't had any other idea how to inject a bean to wicket > page wrapped with Model interface without EL. Now I realize that if I > can get actualType of class form injection point, I can also resolve > targeted bean in typesafe way. SeamModel bean may be very similar to > InstanceImpl class from weld core. What do you think? You mean you need to know the generic type of the injection point?   protected static Type getFacadeType(InjectionPoint injectionPoint)   {      Type genericType = injectionPoint.getType();      if (genericType instanceof ParameterizedType )      {         return ((ParameterizedType) genericType).getActualTypeArguments()[0];      }      else      {         throw new IllegalStateException(TYPE_PARAMETER_MUST_BE_CONCRETE, injectionPoint);      }   } Does that. I would be very against introducing EL into Wicket, it completely removes a key benefit of Wicket.

> > As to benefits, besides saving few lines of code on each page, you get > very safe way of injection beans from any CDI scopes. Injecting > request scope beans into a page isn't safe at all and for some > developers can be not natural. The same applies to situation when your > conversation scope timeouts or was destroyed. If you injected that > bean into wicket page it will hold reference to your object and cause > unstable behavior. >> >>> >>> As I follow seam 3 for some time now I understand that this is time >>> for bugfix rather than adding new features. Is it possible to merge >>> this code before final realese? >>> >>> Second feature is rather small and not soo excited as previous one. >>> I've prepared possiblity to inject ResourceStreamLocator. Deafault is >>> exactly the same as in wicket but I had also developed alternative >>> one, which enables throught configuration to change the place where >>> html file are stored. In my opinion it's also simplification. >>> >> >>  Wicket already has a way to register resource stream locators, I don't see >> why we need a yet another way to do it.  Can you elaborate? > It depends how many features would you like to have in wicket module. > But as I review why I put it in wicket module instead of my project (I > wrote it a month ago), I can't find any strong arguments. It would be > better to have wicket module as simple as possible so forget about it. >> >> -Clint > > Marek Smigielski > > _______________________________________________ > seam-dev mailing list > seam-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev

On 24 Mar 2011, at 13:05, Marek Śmigielski wrote: > On Thu, Mar 24, 2011 at 1:14 PM, Pete Muir <pmuir(a)redhat.com&gt; wrote: >> >> On 23 Mar 2011, at 21:55, Marek Śmigielski wrote: >> >>> On Wed, Mar 23, 2011 at 9:54 PM, Clint Popetz <cpopetz(a)gmail.com&gt; wrote: >>>> >>>> >>>> On Wed, Mar 23, 2011 at 3:02 PM, Marek Śmigielski >>>> <marek.smigielski(a)gmail.com&gt; wrote: >>>>> >>>>> Hi, >>>>> >>>>> In last few day I have deeply thought over wicket modul features >>>>> essential to fully integrate with wicket framework. In wicket >>>>> architecture there is idea of model as a state bean. Its quite >>>>> different in terms of live cycle from scopes provided by CDI. >>>>> >>>>> 1. It is page scope (in some cirumstances more than one http request) >>>>> 2. It is serialized after each request and store in session or disk. >>>>> >>>>> Wicket modules misses integration throught model object with wicket >>>>> architecture so I've developed some integration with it. The idea is >>>>> that you can achieve CDI beans exactly in the same way like in JSF, >>>>> through expressionLanguage. So you can inject any named or other el >>>>> bean via: >>>>> >>>>>   @Inject @ModelExpression("#{nameBean}") >>>>>   private SeamModel<String> label; >>>>> >>>>> and later use it on your page directly: >>>>> >>>>> Label label = new Label("headerLabel", headerLabelModel); >>>>> >>>>> or wrap it by other wicket model: >>>>> >>>>>   @Inject @ModelExpression("#{registartion}") >>>>>   private SeamModel<Registartion> registartion; >>>>> >>>>> >>>>> Form registrationForm = new Form("registartionForm", new >>>>> CompoundPropertyModel(registartion)); >>>>> >>>>> and later use it on whole form. >>>>> >>>> >>>> I'm not sure what benefit this provides.  The wicket page instance is >>>> already a scope, if you wanted something specific to the page, you could >>>> just add it as a field to the page or component.  And EL as a referencing >>>> mechanism is a little too JSF-esque (weakly bound, not refactoring safe) to >>>> be well suited to a wicket integration layer. >>> I think that it's worth to have some way of injection components >>> straight to wicket model beans. Duplication of the fields between >>> wicket page and request component (or any scope component) in my >>> opinion is unnecessary. I agree that EL and wicket concept don't fit >>> well, but I haven't had any other idea how to inject a bean to wicket >>> page wrapped with Model interface without EL. Now I realize that if I >>> can get actualType of class form injection point, I can also resolve >>> targeted bean in typesafe way. SeamModel bean may be very similar to >>> InstanceImpl class from weld core. What do you think? >> >> You mean you need to know the generic type of the injection point? >> >>   protected static Type getFacadeType(InjectionPoint injectionPoint) >>   { >>      Type genericType = injectionPoint.getType(); >>      if (genericType instanceof ParameterizedType ) >>      { >>         return ((ParameterizedType) genericType).getActualTypeArguments()[0]; >>      } >>      else >>      { >>         throw new IllegalStateException(TYPE_PARAMETER_MUST_BE_CONCRETE, injectionPoint); >>      } >>   } >> >> Does that. >> >> I would be very against introducing EL into Wicket, it completely removes a key benefit of Wicket. >> > I understand problem with EL and Wicket. I have modified the way > SeamModel(wrapper over actual bean that implements IModel) is produced > by throwing out qualifier with EL. I have Implemented SeamModel get > wrapped bean method, based on get method of InstanceImpl class and > this one works as expected. I can now inject bean like that: > > @Inject > SeamModel<Registration> registration; > > > but when I have any other qualifier besides @Inject, > > @Inject @UserRegistraion > SeamModel<Registration> registration; > > CDI search for SeamModel bean with this qualifier and throws > unsatisfied dependency injection. What I try to achive is to have > posibilty to inject SeamModel in exactly the same way that Instance > component is injected or to have producer method which satisfied all > qualifiers. In Weld we register Instance as having the @Any qualifier only, which means it resolves for all IPs. Then we apply the qualifiers at the IP at a later date. > > > >>> >>> As to benefits, besides saving few lines of code on each page, you get >>> very safe way of injection beans from any CDI scopes. Injecting >>> request scope beans into a page isn't safe at all and for some >>> developers can be not natural. The same applies to situation when your >>> conversation scope timeouts or was destroyed. If you injected that >>> bean into wicket page it will hold reference to your object and cause >>> unstable behavior. >>>> >>>>> >>>>> As I follow seam 3 for some time now I understand that this is time >>>>> for bugfix rather than adding new features. Is it possible to merge >>>>> this code before final realese? >>>>> >>>>> Second feature is rather small and not soo excited as previous one. >>>>> I've prepared possiblity to inject ResourceStreamLocator. Deafault is >>>>> exactly the same as in wicket but I had also developed alternative >>>>> one, which enables throught configuration to change the place where >>>>> html file are stored. In my opinion it's also simplification. >>>>> >>>> >>>>  Wicket already has a way to register resource stream locators, I don't see >>>> why we need a yet another way to do it.  Can you elaborate? >>> It depends how many features would you like to have in wicket module. >>> But as I review why I put it in wicket module instead of my project (I >>> wrote it a month ago), I can't find any strong arguments. It would be >>> better to have wicket module as simple as possible so forget about it. >>>> >>>> -Clint >>> >>> Marek Smigielski >>> >>> _______________________________________________ >>> seam-dev mailing list >>> seam-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/seam-dev >> >>

On Thu, Mar 24, 2011 at 8:05 AM, Marek Śmigielski <marek.smigielski(a)gmail.com&gt; wrote: > > On Thu, Mar 24, 2011 at 1:14 PM, Pete Muir <pmuir(a)redhat.com&gt; wrote: > > > > On 23 Mar 2011, at 21:55, Marek Śmigielski wrote: > > > >> On Wed, Mar 23, 2011 at 9:54 PM, Clint Popetz <cpopetz(a)gmail.com&gt; > >> wrote: > >>> > >>> > >>> On Wed, Mar 23, 2011 at 3:02 PM, Marek Śmigielski > >>> <marek.smigielski(a)gmail.com&gt; wrote: > >>>> > >>>> Hi, > >>>> > >>>> In last few day I have deeply thought over wicket modul features > >>>> essential to fully integrate with wicket framework. In wicket > >>>> architecture there is idea of model as a state bean. Its quite > >>>> different in terms of live cycle from scopes provided by CDI. > >>>> > >>>> 1. It is page scope (in some cirumstances more than one http request) > >>>> 2. It is serialized after each request and store in session or disk. > >>>> > >>>> Wicket modules misses integration throught model object with wicket > >>>> architecture so I've developed some integration with it. The idea is > >>>> that you can achieve CDI beans exactly in the same way like in JSF, > >>>> through expressionLanguage. So you can inject any named or other el > >>>> bean via: > >>>> > >>>>   @Inject @ModelExpression("#{nameBean}") > >>>>   private SeamModel<String> label; > >>>> > >>>> and later use it on your page directly: > >>>> > >>>> Label label = new Label("headerLabel", headerLabelModel); > >>>> > >>>> or wrap it by other wicket model: > >>>> > >>>>   @Inject @ModelExpression("#{registartion}") > >>>>   private SeamModel<Registartion> registartion; > >>>> > >>>> > >>>> Form registrationForm = new Form("registartionForm", new > >>>> CompoundPropertyModel(registartion)); > >>>> > >>>> and later use it on whole form. > >>>> > >>> > >>> I'm not sure what benefit this provides.  The wicket page instance is > >>> already a scope, if you wanted something specific to the page, you > >>> could > >>> just add it as a field to the page or component.  And EL as a > >>> referencing > >>> mechanism is a little too JSF-esque (weakly bound, not refactoring > >>> safe) to > >>> be well suited to a wicket integration layer. > >> I think that it's worth to have some way of injection components > >> straight to wicket model beans. Duplication of the fields between > >> wicket page and request component (or any scope component) in my > >> opinion is unnecessary. I agree that EL and wicket concept don't fit > >> well, but I haven't had any other idea how to inject a bean to wicket > >> page wrapped with Model interface without EL. Now I realize that if I > >> can get actualType of class form injection point, I can also resolve > >> targeted bean in typesafe way. SeamModel bean may be very similar to > >> InstanceImpl class from weld core. What do you think? > > > > You mean you need to know the generic type of the injection point? > > > >   protected static Type getFacadeType(InjectionPoint injectionPoint) > >   { > >      Type genericType = injectionPoint.getType(); > >      if (genericType instanceof ParameterizedType ) > >      { > >         return ((ParameterizedType) > > genericType).getActualTypeArguments()[0]; > >      } > >      else > >      { > >         throw new IllegalStateException(TYPE_PARAMETER_MUST_BE_CONCRETE, > > injectionPoint); > >      } > >   } > > > > Does that. > > > > I would be very against introducing EL into Wicket, it completely > > removes a key benefit of Wicket. > > > I understand problem with EL and Wicket. I have modified the way > SeamModel(wrapper over actual bean that implements IModel) is produced > by throwing out qualifier with EL. I have Implemented SeamModel get > wrapped bean method, based on get method of InstanceImpl class and > this one works as expected. I can now inject bean like that: > > @Inject > SeamModel<Registration> registration; > > > but when I have any other qualifier besides @Inject, > > @Inject @UserRegistraion > SeamModel<Registration> registration; > > CDI search for SeamModel bean with this qualifier and throws > unsatisfied dependency injection. What I try to achive is to have > posibilty to inject SeamModel in exactly the same way that Instance > component is injected or to have producer method which satisfied all > qualifiers. > Do you have a fork on github I can check out?

 Because I'm still not clear on what is being done.  What gets injected when you inject "registration" above.  Does it store its injection point data and use that to lookup the bean through the BeanManager api on each call to Model.getObject()? -Clint

> > >> > >> As to benefits, besides saving few lines of code on each page, you get > >> very safe way of injection beans from any CDI scopes. Injecting > >> request scope beans into a page isn't safe at all and for some > >> developers can be not natural. The same applies to situation when your > >> conversation scope timeouts or was destroyed. If you injected that > >> bean into wicket page it will hold reference to your object and cause > >> unstable behavior. > >>> > >>>> > >>>> As I follow seam 3 for some time now I understand that this is time > >>>> for bugfix rather than adding new features. Is it possible to merge > >>>> this code before final realese? > >>>> > >>>> Second feature is rather small and not soo excited as previous one. > >>>> I've prepared possiblity to inject ResourceStreamLocator. Deafault is > >>>> exactly the same as in wicket but I had also developed alternative > >>>> one, which enables throught configuration to change the place where > >>>> html file are stored. In my opinion it's also simplification. > >>>> > >>> > >>>  Wicket already has a way to register resource stream locators, I > >>> don't see > >>> why we need a yet another way to do it.  Can you elaborate? > >> It depends how many features would you like to have in wicket module. > >> But as I review why I put it in wicket module instead of my project (I > >> wrote it a month ago), I can't find any strong arguments. It would be > >> better to have wicket module as simple as possible so forget about it. > >>> > >>> -Clint > >> > >> Marek Smigielski > >> > >> _______________________________________________ > >> seam-dev mailing list > >> seam-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/seam-dev > > > > -- Clint Popetz http://42lines.net Scalable Web Application Development