Removing models and clearing all models
34 views
Skip to first unread message
Neil Griffin
Jan 25, 2019, 5:30:01 PM1/25/19
to MVC 1.0 Users Mailing List
Would it be possible to add remove(String) and clear() methods to the Models interface?
The developer has the ability to mutate the Models implementation with the put(String, Object) method, but has no way to remove attributes from the underlying map or to clear the underlying map.
Daniel Dias Dos Santos
Jan 25, 2019, 5:40:17 PM1/25/19
to jsr371...@googlegroups.com
Hello Neil,
welcome : )
Could you explain your request better?
--
Daniel Dias dos Santos
Daniel Dias dos Santos
Java Developer
SouJava & JCP MemberGitHub: https://github.com/Daniel-Dos
Linkedin: www.linkedin.com/in/danieldiasjavaTwitter: http://twitter.com/danieldiasjava
--
You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com.
To post to this group, send email to jsr371...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jsr371-users/b9b9aa6b-edd8-40fa-bbab-961d3389208a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Neil Griffin
Jan 25, 2019, 5:54:52 PM1/25/19
to jsr371...@googlegroups.com
Hi Daniel,
I noticed that in 1.0-pr the Models interface used to extend Map<String,Object> and Iterable<String>:
https://static.javadoc.io/javax.mvc/javax.mvc-api/1.0-pr/javax/mvc/Models.html
But this was changed in 1.0-pfd to simply extend Iterable<String>:
https://static.javadoc.io/javax.mvc/javax.mvc-api/1.0-pfd/javax/mvc/Models.html
This causes two problems:
1) No way to remove attributes or clear attributes, as the Map interface provided
2) The "models" EL keyword can no longer be used with the "map" referencing functionality of EL. For example: "${models['foo']}"
I suppose that #2 is not a very big deal though, because I noticed that the ServletViewEngine sets request attributes from the model:
final Models models = context.getModels();
for (String name : models) {
request.setAttribute(name, models.get(name));
}
Thanks,
Neil
On 1/25/19 5:40 PM, Daniel Dias Dos Santos wrote:
> Hello Neil,
>
> welcome : )
>
> Could you explain your request better?
> --*
> Daniel Dias dos Santos
> *
> Linkedin: www.linkedin.com/in/danieldiasjava <http://www.linkedin.com/in/danieldiasjava>
> To post to this group, send email to jsr371...@googlegroups.com <mailto:jsr371...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jsr371-users/b9b9aa6b-edd8-40fa-bbab-961d3389208a%40googlegroups.com <https://groups.google.com/d/msgid/jsr371-users/b9b9aa6b-edd8-40fa-bbab-961d3389208a%40googlegroups.com?utm_medium=email&utm_source=footer>.
> To post to this group, send email to jsr371...@googlegroups.com <mailto:jsr371...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jsr371-users/CAOuqdjPG4kn_DxhVzVQFnodUCni7SrW4k0%3DRK_hQtvyDrg3yyw%40mail.gmail.com <https://groups.google.com/d/msgid/jsr371-users/CAOuqdjPG4kn_DxhVzVQFnodUCni7SrW4k0%3DRK_hQtvyDrg3yyw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
I noticed that in 1.0-pr the Models interface used to extend Map<String,Object> and Iterable<String>:
https://static.javadoc.io/javax.mvc/javax.mvc-api/1.0-pr/javax/mvc/Models.html
But this was changed in 1.0-pfd to simply extend Iterable<String>:
https://static.javadoc.io/javax.mvc/javax.mvc-api/1.0-pfd/javax/mvc/Models.html
This causes two problems:
1) No way to remove attributes or clear attributes, as the Map interface provided
2) The "models" EL keyword can no longer be used with the "map" referencing functionality of EL. For example: "${models['foo']}"
I suppose that #2 is not a very big deal though, because I noticed that the ServletViewEngine sets request attributes from the model:
final Models models = context.getModels();
for (String name : models) {
request.setAttribute(name, models.get(name));
}
Thanks,
Neil
On 1/25/19 5:40 PM, Daniel Dias Dos Santos wrote:
> Hello Neil,
>
> welcome : )
>
> Could you explain your request better?
> Daniel Dias dos Santos
> *
> Linkedin: www.linkedin.com/in/danieldiasjava <http://www.linkedin.com/in/danieldiasjava>
> Twitter: http://twitter.com/danieldiasjava
>
>
> Em sex, 25 de jan de 2019 às 20:30, Neil Griffin <ngrif...@gmail.com <mailto:ngrif...@gmail.com>> escreveu:
>
> Would it be possible to add remove(String) and clear() methods to the Models interface?
> https://static.javadoc.io/javax.mvc/javax.mvc-api/1.0-pfd/javax/mvc/Models.html
>
> The developer has the ability to mutate the Models implementation with the put(String, Object) method, but has no way to remove attributes from the underlying map or to clear the underlying map.
>
> --
> You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com <mailto:jsr371-users...@googlegroups.com>.
>
>
> Em sex, 25 de jan de 2019 às 20:30, Neil Griffin <ngrif...@gmail.com <mailto:ngrif...@gmail.com>> escreveu:
>
> Would it be possible to add remove(String) and clear() methods to the Models interface?
> https://static.javadoc.io/javax.mvc/javax.mvc-api/1.0-pfd/javax/mvc/Models.html
>
> The developer has the ability to mutate the Models implementation with the put(String, Object) method, but has no way to remove attributes from the underlying map or to clear the underlying map.
>
> --
> You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
> To post to this group, send email to jsr371...@googlegroups.com <mailto:jsr371...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jsr371-users/b9b9aa6b-edd8-40fa-bbab-961d3389208a%40googlegroups.com <https://groups.google.com/d/msgid/jsr371-users/b9b9aa6b-edd8-40fa-bbab-961d3389208a%40googlegroups.com?utm_medium=email&utm_source=footer>.
> --
> You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com <mailto:jsr371-users...@googlegroups.com>.
> You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
> To post to this group, send email to jsr371...@googlegroups.com <mailto:jsr371...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jsr371-users/CAOuqdjPG4kn_DxhVzVQFnodUCni7SrW4k0%3DRK_hQtvyDrg3yyw%40mail.gmail.com <https://groups.google.com/d/msgid/jsr371-users/CAOuqdjPG4kn_DxhVzVQFnodUCni7SrW4k0%3DRK_hQtvyDrg3yyw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Christian Kaltepoth
Jan 26, 2019, 12:31:10 AM1/26/19
to MVC 1.0 Users
Hey Neil,
thanks for your feedback. I'm really happy to see that you are reviewing the latest draft of the spec. :-)
Yes, we changed the Models interface in the PFD version of the spec. See the corresponding issue and the pull request for more information about the reasons for this change.
Regarding your concerns:
- Yes, currently you cannot clear the models instance or remove individual entries from it. But to be honest, I don't think this is something that a developer really needs. Usually you collect data in your controller (from the database or something like that) and store view models in the Models instance. But why should I clear it? Usually the controller method is quite simple. It gets data from somewhere and stores it in the model. BTW: If you really need to remove something from Models, you could still overwrite it with "null", which would have the same effect as removing it. However, I really doubt that somebody needs to do that in real world apps.
- Actually I wasn't aware that our change breaks the ability to use JSP map syntax. But as you already wrote this isn't really a problem, because we don't expose the model as a "model" EL variable but instead make all the individual entries available in the EL context. So I don't think this is a real issue.
Not sure how others feel about this!?
Christian
To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com.
To post to this group, send email to jsr371...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jsr371-users/771f5962-bd76-5894-4dff-f74930533cae%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Florian Hirsch
Jan 26, 2019, 6:19:10 AM1/26/19
to jsr371...@googlegroups.com
Hi Neil,
do you have any use-cases in mind? I first thought about removing model attributes in a generic AfterControllerEvent but I saw that you can't access models there. (OT: but would that make sense?)
Regarding the missing map syntax: would it make sense to clarify in the spec at least how view Engines should give access to models?
best
Flo
To view this discussion on the web visit https://groups.google.com/d/msgid/jsr371-users/CAEXeC6yKLcDx-WR38mg0DTF4xy8x5NMdSoFTLbZ7uSaBsx6oqg%40mail.gmail.com.
Christian Kaltepoth
Jan 26, 2019, 12:14:47 PM1/26/19
to MVC 1.0 Users
@Florian:
If you @Observe AfterControllerEvent in a CDI bean, you could also inject Models into the same bean. So accessing the Models instance should be easy.
Regarding clarification on how ViewEngines give access to models. IIRC this is more or less clearly specified. But maybe I'm wrong. Of course, we could make this more explicit if required.
Christian
To view this discussion on the web visit https://groups.google.com/d/msgid/jsr371-users/CADO3Jtn1-t2%2B1fGdfqpU9Dr5u1r8vW5Q7JmLQnrx877NhN55eg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Florian Hirsch
Jan 26, 2019, 1:51:44 PM1/26/19
to jsr371...@googlegroups.com
Thanks for your answer Christian. You're right:
>Prior to the view render phase, all entries available in Models MUST be bound in such a way that
they become available to the view being processed. The exact mechanism for this depends on the
actual view engine implementation. In the case of the built-in view engines for JSPs and Facelets,
entries in Models must be bound by calling HttpServletRequest.setAttribute(String, Object).
Calling this method ensures access to the named models from EL expressions.
This is explicit enough.
Flo
To view this discussion on the web visit https://groups.google.com/d/msgid/jsr371-users/CAEXeC6zJZYaCtRYeicnOLqvGka1oZFHO2e1%3D%3Dj-F%3D74S0dJnNA%40mail.gmail.com.
Neil Griffin
Jan 26, 2019, 6:24:35 PM1/26/19
to jsr371...@googlegroups.com
@Florian: Regarding your question about a specific use-case, I am doing research into the requirements for supporting usage of the MVC 1.0 in a portlet environment -- that is actually the context of most of my questions lately.
One important difference between a servlet-based webapp and a portlet-based application is that the portlet lifecycle is based on a post-redirect-get type of design pattern.
In JAX-RS terms, portlet application form submissions always behave like this:
@Inject Models models;
@POST
@Controller
public String submitForm() {
models.put("abcd", "1234");
return "redirect:/mvc/foo";
}
@GET
@Controller
@View("view.jsp")
public String prepareView() {
System.err.println("abcd=" + models.get("abcd"));
}
Because of this, the instance of javax.mvc.Models has to be stored in something similar to @RedirectScoped so that it survives from the HTTP POST request into the subsequent HTTP GET request.
Back to the question about the use-case, I can foresee the possibility of the portlet developer wanting to remove a model attribute or clear the model attributes in the @GET controller method. Additionally, if a developer wanted to provide a CDI @Alternative for Models, then having more methods that control the underlying map would be a more helpful/flexible API.
Neil
On 1/26/19 1:51 PM, Florian Hirsch wrote:
> Thanks for your answer Christian. You're right:
>
> >Prior to the view render phase, all entries available in Models MUST be bound in such a way that they become available to the view being processed. The exact mechanism for this depends on the actual view engine implementation. In the case of the built-in view engines for JSPs and Facelets, entries in Models must be bound by calling HttpServletRequest.setAttribute(String, Object). Calling this method ensures access to the named models from EL expressions.
>
> This is explicit enough.
>
> Flo
>
>>>
>>> Regarding your concerns:
>>>
>>> 1. Yes, currently you cannot clear the models instance or remove individual entries from it. But to be honest, I don't think this is something that a developer really needs. Usually you collect data in your controller (from the database or something like that) and store view models in the Models instance. But why should I clear it? Usually the controller method is quite simple. It gets data from somewhere and stores it in the model. BTW: If you really need to remove something from Models, you could still overwrite it with "null", which would have the same effect as removing it. However, I really doubt that somebody needs to do that in real world apps.
>>> 2. Actually I wasn't aware that our change breaks the ability to use JSP map syntax. But as you already wrote this isn't really a problem, because we don't expose the model as a "model" EL variable but instead make all the individual entries available in the EL context. So I don't think this is a real issue.
>>> > Linkedin: www.linkedin.com/in/danieldiasjava <http://www.linkedin.com/in/danieldiasjava> <http://www.linkedin.com/in/danieldiasjava>
>>> > To post to this group, send email to jsr371...@googlegroups.com <mailto:jsr371...@googlegroups.com> <mailto:jsr371...@googlegroups.com <mailto:jsr371...@googlegroups.com>>.
>>> > To post to this group, send email to jsr371...@googlegroups.com <mailto:jsr371...@googlegroups.com> <mailto:jsr371...@googlegroups.com <mailto:jsr371...@googlegroups.com>>.
One important difference between a servlet-based webapp and a portlet-based application is that the portlet lifecycle is based on a post-redirect-get type of design pattern.
In JAX-RS terms, portlet application form submissions always behave like this:
@Inject Models models;
@POST
@Controller
public String submitForm() {
models.put("abcd", "1234");
return "redirect:/mvc/foo";
}
@GET
@Controller
@View("view.jsp")
public String prepareView() {
System.err.println("abcd=" + models.get("abcd"));
}
Because of this, the instance of javax.mvc.Models has to be stored in something similar to @RedirectScoped so that it survives from the HTTP POST request into the subsequent HTTP GET request.
Back to the question about the use-case, I can foresee the possibility of the portlet developer wanting to remove a model attribute or clear the model attributes in the @GET controller method. Additionally, if a developer wanted to provide a CDI @Alternative for Models, then having more methods that control the underlying map would be a more helpful/flexible API.
Neil
On 1/26/19 1:51 PM, Florian Hirsch wrote:
> Thanks for your answer Christian. You're right:
>
> >Prior to the view render phase, all entries available in Models MUST be bound in such a way that they become available to the view being processed. The exact mechanism for this depends on the actual view engine implementation. In the case of the built-in view engines for JSPs and Facelets, entries in Models must be bound by calling HttpServletRequest.setAttribute(String, Object). Calling this method ensures access to the named models from EL expressions.
>
> This is explicit enough.
>
> Flo
>
> Am 26. Januar 2019 um 18:14:48, Christian Kaltepoth (chri...@kaltepoth.de <mailto:chri...@kaltepoth.de>) schrieb:
>
>> @Florian:
>>
>> If you @Observe AfterControllerEvent in a CDI bean, you could also inject Models into the same bean. So accessing the Models instance should be easy.
>>
>> Regarding clarification on how ViewEngines give access to models. IIRC this is more or less clearly specified. But maybe I'm wrong. Of course, we could make this more explicit if required.
>>
>> Christian
>>
>
>> @Florian:
>>
>> If you @Observe AfterControllerEvent in a CDI bean, you could also inject Models into the same bean. So accessing the Models instance should be easy.
>>
>> Regarding clarification on how ViewEngines give access to models. IIRC this is more or less clearly specified. But maybe I'm wrong. Of course, we could make this more explicit if required.
>>
>> Christian
>>
>> Am Sa., 26. Jan. 2019 um 12:19 Uhr schrieb Florian Hirsch <po...@florianhirsch.de <mailto:po...@florianhirsch.de>>:
>>
>> Hi Neil,
>>
>> do you have any use-cases in mind? I first thought about removing model attributes in a generic AfterControllerEvent but I saw that you can't access models there. (OT: but would that make sense?)
>>
>> Regarding the missing map syntax: would it make sense to clarify in the spec at least how view Engines should give access to models?
>>
>> best
>> Flo
>>
>>
>> Hi Neil,
>>
>> do you have any use-cases in mind? I first thought about removing model attributes in a generic AfterControllerEvent but I saw that you can't access models there. (OT: but would that make sense?)
>>
>> Regarding the missing map syntax: would it make sense to clarify in the spec at least how view Engines should give access to models?
>>
>> best
>> Flo
>>
>> Am 26. Januar 2019 um 06:31:10, Christian Kaltepoth (chri...@kaltepoth.de <mailto:chri...@kaltepoth.de>) schrieb:
>>
>>> Hey Neil,
>>>
>>> thanks for your feedback. I'm really happy to see that you are reviewing the latest draft of the spec. :-)
>>>
>>> Yes, we changed the Models interface in the PFD version of the spec. See the corresponding issue <https://github.com/mvc-spec/mvc-spec/issues/40> and the pull request <https://github.com/mvc-spec/mvc-spec/pull/171> for more information about the reasons for this change.
>>
>>> Hey Neil,
>>>
>>> thanks for your feedback. I'm really happy to see that you are reviewing the latest draft of the spec. :-)
>>>
>>>
>>> Regarding your concerns:
>>>
>>> 1. Yes, currently you cannot clear the models instance or remove individual entries from it. But to be honest, I don't think this is something that a developer really needs. Usually you collect data in your controller (from the database or something like that) and store view models in the Models instance. But why should I clear it? Usually the controller method is quite simple. It gets data from somewhere and stores it in the model. BTW: If you really need to remove something from Models, you could still overwrite it with "null", which would have the same effect as removing it. However, I really doubt that somebody needs to do that in real world apps.
>>> 2. Actually I wasn't aware that our change breaks the ability to use JSP map syntax. But as you already wrote this isn't really a problem, because we don't expose the model as a "model" EL variable but instead make all the individual entries available in the EL context. So I don't think this is a real issue.
>>> > Twitter: http://twitter.com/danieldiasjava
>>> >
>>> >
>>> > Em sex, 25 de jan de 2019 às 20:30, Neil Griffin <ngrif...@gmail.com <mailto:ngrif...@gmail.com> <mailto:ngrif...@gmail.com <mailto:ngrif...@gmail.com>>> escreveu:
>>> >
>>> > Would it be possible to add remove(String) and clear() methods to the Models interface?
>>> > https://static.javadoc.io/javax.mvc/javax.mvc-api/1.0-pfd/javax/mvc/Models.html
>>> >
>>> > The developer has the ability to mutate the Models implementation with the put(String, Object) method, but has no way to remove attributes from the underlying map or to clear the underlying map.
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com <mailto:jsr371-users%2Bunsu...@googlegroups.com> <mailto:jsr371-users...@googlegroups.com <mailto:jsr371-users%2Bunsu...@googlegroups.com>>.
>>> >
>>> >
>>> > Em sex, 25 de jan de 2019 às 20:30, Neil Griffin <ngrif...@gmail.com <mailto:ngrif...@gmail.com> <mailto:ngrif...@gmail.com <mailto:ngrif...@gmail.com>>> escreveu:
>>> >
>>> > Would it be possible to add remove(String) and clear() methods to the Models interface?
>>> > https://static.javadoc.io/javax.mvc/javax.mvc-api/1.0-pfd/javax/mvc/Models.html
>>> >
>>> > The developer has the ability to mutate the Models implementation with the put(String, Object) method, but has no way to remove attributes from the underlying map or to clear the underlying map.
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
>>> > To post to this group, send email to jsr371...@googlegroups.com <mailto:jsr371...@googlegroups.com> <mailto:jsr371...@googlegroups.com <mailto:jsr371...@googlegroups.com>>.
>>> > To view this discussion on the web visit https://groups.google.com/d/msgid/jsr371-users/b9b9aa6b-edd8-40fa-bbab-961d3389208a%40googlegroups.com <https://groups.google.com/d/msgid/jsr371-users/b9b9aa6b-edd8-40fa-bbab-961d3389208a%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>> > For more options, visit https://groups.google.com/d/optout.
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com <mailto:jsr371-users%2Bunsu...@googlegroups.com> <mailto:jsr371-users...@googlegroups.com <mailto:jsr371-users%2Bunsu...@googlegroups.com>>.
>>> > For more options, visit https://groups.google.com/d/optout.
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
>>> > To post to this group, send email to jsr371...@googlegroups.com <mailto:jsr371...@googlegroups.com> <mailto:jsr371...@googlegroups.com <mailto:jsr371...@googlegroups.com>>.
>>> > To view this discussion on the web visit https://groups.google.com/d/msgid/jsr371-users/CAOuqdjPG4kn_DxhVzVQFnodUCni7SrW4k0%3DRK_hQtvyDrg3yyw%40mail.gmail.com <https://groups.google.com/d/msgid/jsr371-users/CAOuqdjPG4kn_DxhVzVQFnodUCni7SrW4k0%3DRK_hQtvyDrg3yyw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com <mailto:jsr371-users%2Bunsu...@googlegroups.com>.
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
>>> To post to this group, send email to jsr371...@googlegroups.com <mailto:jsr371...@googlegroups.com>.
>>> To view this discussion on the web visit https://groups.google.com/d/msgid/jsr371-users/771f5962-bd76-5894-4dff-f74930533cae%40gmail.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>>> --
>>> Christian Kaltepoth
>>> Blog: http://blog.kaltepoth.de/
>>> Twitter: http://twitter.com/chkal
>>> GitHub: https://github.com/chkal
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>>> --
>>> Christian Kaltepoth
>>> Blog: http://blog.kaltepoth.de/
>>> Twitter: http://twitter.com/chkal
>>> GitHub: https://github.com/chkal
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com <mailto:jsr371-users...@googlegroups.com>.
>>> To post to this group, send email to jsr371...@googlegroups.com <mailto:jsr371...@googlegroups.com>.
>>> To view this discussion on the web visit https://groups.google.com/d/msgid/jsr371-users/CAEXeC6yKLcDx-WR38mg0DTF4xy8x5NMdSoFTLbZ7uSaBsx6oqg%40mail.gmail.com <https://groups.google.com/d/msgid/jsr371-users/CAEXeC6yKLcDx-WR38mg0DTF4xy8x5NMdSoFTLbZ7uSaBsx6oqg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>>> To post to this group, send email to jsr371...@googlegroups.com <mailto:jsr371...@googlegroups.com>.
>>> For more options, visit https://groups.google.com/d/optout.
>> --
>> You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com <mailto:jsr371-users...@googlegroups.com>.
>> To post to this group, send email to jsr371...@googlegroups.com <mailto:jsr371...@googlegroups.com>.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/jsr371-users/CADO3Jtn1-t2%2B1fGdfqpU9Dr5u1r8vW5Q7JmLQnrx877NhN55eg%40mail.gmail.com <https://groups.google.com/d/msgid/jsr371-users/CADO3Jtn1-t2%2B1fGdfqpU9Dr5u1r8vW5Q7JmLQnrx877NhN55eg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>> --
>> You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com <mailto:jsr371-users...@googlegroups.com>.
>> To post to this group, send email to jsr371...@googlegroups.com <mailto:jsr371...@googlegroups.com>.
>> Christian Kaltepoth
>> Blog: http://blog.kaltepoth.de/
>> Twitter: http://twitter.com/chkal
>> GitHub: https://github.com/chkal
>>
>> --
>> You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
>> Blog: http://blog.kaltepoth.de/
>> Twitter: http://twitter.com/chkal
>> GitHub: https://github.com/chkal
>>
>> --
>> You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com <mailto:jsr371-users...@googlegroups.com>.
>> To post to this group, send email to jsr371...@googlegroups.com <mailto:jsr371...@googlegroups.com>.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/jsr371-users/CAEXeC6zJZYaCtRYeicnOLqvGka1oZFHO2e1%3D%3Dj-F%3D74S0dJnNA%40mail.gmail.com <https://groups.google.com/d/msgid/jsr371-users/CAEXeC6zJZYaCtRYeicnOLqvGka1oZFHO2e1%3D%3Dj-F%3D74S0dJnNA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>> To post to this group, send email to jsr371...@googlegroups.com <mailto:jsr371...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com <mailto:jsr371-users...@googlegroups.com>.
> To post to this group, send email to jsr371...@googlegroups.com <mailto:jsr371...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jsr371-users/CADO3JtkCHSuecWyC_%3DSXe2tYC3m%3D__yZs1nOT0NgiyZasKLinw%40mail.gmail.com <https://groups.google.com/d/msgid/jsr371-users/CADO3JtkCHSuecWyC_%3DSXe2tYC3m%3D__yZs1nOT0NgiyZasKLinw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google Groups "MVC 1.0 Users Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com <mailto:jsr371-users...@googlegroups.com>.
> To post to this group, send email to jsr371...@googlegroups.com <mailto:jsr371...@googlegroups.com>.
Christian Kaltepoth
Jan 27, 2019, 5:29:37 AM1/27/19
to MVC 1.0 Users
Hi Neil,
thanks a lot for sharing these details. I'm not familiar with portlet environments, so my following thoughts may be totally wrong or not be applicable to your use case. :-)
The primary role the Models class is to transfer data from the controller to the view within a single request. The PRG pattern is also supported by MVC using the @RedirectScoped annotation for CDI models.
In the example you provided it would be the responsibility of the "prepareView" method to populate the Models instance with all data required for the view. It is important to do it there, so that the view can render either if the page is requested directly (via an initial GET, only "prepareView" is called) or as a result after a form has been processed (PRG pattern, first "submitForm" and then "prepareView" is invoked).
Of course there are situations where you want to transfer some data from the controller processing the form post to either the controller handling the following GET or to the view rendered as response to this GET. However, this would typically be achieved using a separate CDI model with a @RedirectScoped annotation.
As mentioned before, my knowledge about portlet environments is very limited, so this all may or may not make sense for your use case.
Best regards
Christian
To unsubscribe from this group and stop receiving emails from it, send an email to jsr371-users...@googlegroups.com.
To post to this group, send email to jsr371...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jsr371-users/e25e7ccf-94d3-7169-07d1-c479fa97b11e%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages