myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <lu4...@gmail.com>
Subject Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
Date Tue, 29 Apr 2014 18:02:40 GMT
Hi

I have done a fast prototype, just to check how things could work and how the
pieces can be grouped together, and there are some interesting ideas that are
worth to consider.

In JSF 2, when f:viewParam was added, some logic was added to create the view
in two steps: first you create the view metadata, where f:viewParam and now
f:viewAction lives and then you "fill" the view, executing facelets algorithm
again and in that way create the full component hierarchy.

One idea it came to my mind is create a ViewDeclarationLanguage wrapper and
override getViewMetadata(...) method to inject a f:viewAction component
according to the definition in the CDI bean. For example:

@Named("sayHelloBean")
@ActionController
@RequestScoped
public class SayHelloBean
{

    @ViewAction("/section1/*")
    public String method2()
    {

That makes all views that match with the pattern provided to have an extra
f:viewAction component, with the existing rules that apply for them. You can
also imagine something like this:

    @ViewAction("/section1/*")
    public String method2(@ViewParam String param1)

What we are saying with the syntax is: "... all views that are are part of
section1 will have a ViewAction listener and will have a view param called
param1. ...".

This approach the following advantages:

- Provide a way to define view actions without override the html markup in
  every top level template page.
- It reuse the existing logic for JSF view action, so it is easy to understand
  for the users.
- It can be included in JSF 2.2.
- JSF is still in control of the navigation at all times, because there is no
  Front Controller.
- The context will be automatically managed by JSF.

but also has the following limitations:

- With an action source framework it is possible to define a wide range of
conditions to activate the action. For example if the request is a GET or a
POST, of if it sends some specific header, even take parameters from the path.
In this solution, the viewId is used for pattern maching and only considers
query parameters.
- It bounds the action to a view, so if there is no view, there is no action.


And we finally get to the central point of discussion: How much flexibility we
really need or the users want to define view actions?

Remember the first lines in JSF spec:

"... JSF’s core architecture is designed to be independent of specific
protocols and markup. ..."

Now take a look for example about what JAX-RS spec says about:

"... The following are the goals of the API: POJO-based, HTTP-centric,
Format independence, Container independence, Inclusion in Java EE ..."

In that sense, all other features provided by action source frameworks are
just useless for JSF, besides include a way to declare view actions into
CDI beans.

If we review the related requeriments Thomas Andraschko provided:

1) possibility to use a normal JSF lifecycle for the first GET request
2) allow action handling and custom response for POST actions
3) normal action handling like in asp.net MVC + a EL util function to
   generate the action URL

I think with the approach proposed we can comply with the requirements.

Maybe we should forget about the rest, and focus our efforts in explore
this approach.

DR>> +1 for the idea. Are you going to have two sets of  release jars with
DR>> and without extensions ? Is it going to be a different project?

It is still a proposal (please read the subject of the message), so it
is too early to say something about.

DR>> Spring MVC beans can be configured to be accessed from the ManagedBeans.
DR>> You are talking about the spring beans integration in the jsf elements?

The mail is clear in this. The idea is explore how to do things like with
an action source framework, but in JSF 2.2 / CDI, probably writing a CDI
extension. There is no integration code with a third party framework, the
idea is found new ways to solve existing problems.

regards,

Leonardo Uribe

2014-04-29 18:32 GMT+02:00 Dora Rajappan <dorarajappan@yahoo.com>:
> +1 for the idea. Are you going to have two sets of  release jars with and
> without extensions ? Is it going to be a different project?
>
> Spring MVC beans can be configured to be accessed from the ManagedBeans. You
> are talking about the spring beans integration in the jsf elements?
>
> Regards,
> Dora Rajappan.
> On Friday, April 25, 2014 7:03 PM, Thomas Andraschko
> <andraschko.thomas@gmail.com> wrote:
> Hi,
>
> sounds good enough for a first prototype -> +1
>
> Regards,
> Thomas
>
>
> 2014-04-25 15:23 GMT+02:00 Leonardo Uribe <lu4242@gmail.com>:
>
> Hi
>
> There are different things we would like to include in this module. For
> now, let's focus on rethink how "actions" should be processed in JSF.
>
> To make things easier, let's start with a comparison between f:viewAction
> and
> a solution that involves a front controller and some actions defines using
> annotations in a CDI bean.
>
> In the first case, the developer defines the action in the page using a tag:
>
> SOLUTION 1:
>
> <f:metadata>
>     <f:viewParam name="id" value="#{personPage.id}"/>
>     <f:viewAction action="#{personPage.loadPerson}"/>
> </f:metadata>
>
> The alternative approach to discuss here is use a managed bean that defines
> a path that will work as an starting point:
>
> SOLUTION 2:
>
> @Named("myBean")
> @ActionController
> @RequestScoped
> public class MyBean
> {
>     @Action("/actions/do/something")
>     // userId param with automatic converter lookup
>     public View myAction()
>     {
>        return new View("/views/registration/startRegistration.xhtml");
>     }
> }
>
> There are multiple differences between both solutions:
>
>  * <f:viewAction> requires a view to be defined, so when the f:viewAction is
>    processed, there is a FacesContext, a client window set (if any) and
> there
>    is a view context too. With the annotations there is no associated view,
>    so it can't be a valid UIViewRoot at that moment.
>
>  * The annotation approach allows navigation without being in a view. With
>    f:viewAction it is possible to cause a navigation like with a
>    h:commandButton.
>
>  * f:viewAction still requires a managed bean to handle the action. The
> syntax
>    using annotations is more compact, because requires only the managed
> bean.
>
>  * f:viewAction is activated every time the page is loaded by first time
>    (in practice, every time a GET is processed), but with the annotations
>    it is necessay to define the conditions under the action is activated.
>
> I think f:viewAction and the annotation approach are different things, even
> if they share some similarities.
>
> JSF has been always a "page centric" framework. The developer write some
> pages, but to define the navigation, the developer has the option of write
> some navigation rules or he/she can also use an implicit navigation.
>
> f:viewAction design fits really well with JSF, as long as you are dealing
> with
> "view actions". But in some cases, the action doesn't have any relationship
> with any view. That's the case where an action defined into a managed bean
> has
> sense.
>
> For example, when the user want to verify a condition for all pages inside
> a folder. If the condition is not valid, an specified page should be
> rendered.
> Some solutions for that problem are:
>
> 1. Create a filter and handle the logic there
> 2. Create a ViewHandler wrapper, override createView(...) and handle the
> logic
> there.
>
> But it would be nice to have something like this:
>
> @Named("myBean")
> @ActionController
> @RequestScoped
> public class CheckUserBean
> {
>     @Priority(Priorities.USER)
>     @Action("/registration/*")
>     // userId param with automatic converter lookup
>     public View myAction()
>     {
>        if (the current flow is not active)
>        {
>            return new Navigation("registration");
>        }
>        // Otherwise continue to the expected page
>        return null;
>     }
> }
>
> In this case we have an action that is executed based on a pattern, in a
> specified moment, for a set of pages, and that could cause a navigation
> to another page or could not affect the navigation and JSF lifecycle takes
> place as usual.
>
> The other kind of action proposed:
>
>     @Action("/actions/do/something")
>     // userId param with automatic converter lookup
>     public View myAction()
>     {
>        return new View("/views/registration/startRegistration.xhtml");
>     }
>
> It can be something like this too:
>
>     @Action("/actions/do/something")
>     // userId param with automatic converter lookup
>     public void myAction()
>     {
>        FacesContext facesContext = FacesContext.getCurrentInstance();
>
>        /* ... generate text, pdf, xml or whatever ...*/
>
>        facesContext.responseComplete();
>     }
>
> the responseComplete() cause the lifecycle to be skipped.
>
> I think these ideas does not overlap or replace the utility of f:viewAction,
> and instead the aim is solve a different problem. I'll try to make a
> prototype with the ideas exposed here. I have some more ideas for the other
> requeriments we have, but for now the idea is focus on what looks more
> important or useful.
>
> Suggestions are welcome.
>
> regards,
>
> Leonardo
>
> 2014-04-23 15:45 GMT+02:00 Leonardo Uribe <lu4242@gmail.com>:
>> Hi
>>
>> 2014-04-23 14:16 GMT+02:00 Thomas Andraschko
>> <andraschko.thomas@gmail.com>:
>>> LU>> 4) Allow action rendering in in a normal lifecycle:
>>> LU>>
>>> LU>>    <ui:renderAction action="#{myBrean.myAction(
>>> LU>bean.value, 1)}" />
>>> LU>>
>>> LU>
>>> LU>Could you please describe better this case? So you execute the action,
>>> LU> but the lifecycle goes on as usual?
>>
>>
>> TA> It's just a component, which renders the returned html string from the
>> TA> action into the ResponseWriter.
>> TA> Something like a include for the action return value.
>> TA>
>> TA>
>> TA> This would be also helpful if we combine facelet rendering + actions.
>> TA> In ASP.NET MVC, the action could also return a View/PartialView:
>> TA>
>> TA>
>> TA>>     @Named("myBean")
>> TA>>     @RequestScoped
>> TA>>     public class MyBean {
>> TA>>          @Action
>> TA>>          // userId param with automatic converter lookup
>> TA>>          public PartialView myAction(String myUrlParam, User userId)
>> {
>> TA>>               return new
>> TA>> PartialView("/META-INF/mylib/myincludes/myfile.xhtml");
>> TA>>          }
>> TA>>      }
>> TA>
>> TA> It would load the xhtml, renders the xhtml and return the rendered
>> html
>> TA> string - called via ui:renderAction or via URL.
>> TA>
>>
>> So you mean use JSF as a template engine to render some html fragments.
>> I think it can be done.
>>
>> This feature is something controversial, because it could be used wrongly.
>> For example, you have a page fragment and you want to update it using
>> this stuff and some javascript. Since you are bypassing JSF, the results
>> can be unexpected, because JSF is no longer in control of the view state
>> anymore. The right way is affect the component state (or the model state),
>> so when it is rendered it gets updated. The best way to do it, is with
>> ajax,
>> because ajax knows about the relationship between different components.
>>
>> Also, you could have situations when the ids are not correctly generated,
>> and at the end have duplicate ids. Again, the solution is add or remove
>> the
>> component from the component tree programmatically, so JSF can have
>> the change to deal with this problem properly.
>>
>> More than a PartialView, I think in this case JSF is used as a raw html or
>> xml generator. For example, the html in this case could be a formatted
>> message and so on.
>>
>> I think it is better if we avoid the term "PartialView" and instead we
>> provide
>> something more abstract like "Response" or "MarkupFragment" or
>> something like that. Something that indicates that this is not part of the
>> view itself, and instead is part of the "client state".
>>
>>>
>>>
>>> I think we could also completely rebuild the GET functionality for
>>> actions.
>>> Maybe could just render the startRegistration.xhtml via a normal JSF
>>> lifecycle after the action call.
>>>
>>>>     @Named("myBean")
>>>>     @RequestScoped
>>>>     public class MyBean {
>>>>          @Action(mapping = "/actions/do/something")
>>>
>>>>          // userId param with automatic converter lookup
>>>>          public View myAction() {
>>>>               return new
>>>> View("/views/registration/startRegistration.xhtml");
>>>>          }
>>>>      }
>>>
>>
>> It can be done. In fact, it works like a url rewriting. Maybe it is more
>> straighforward for users after all, because with f:viewAction, you can't
>> control the page, but with this, you can add some logic before the
>> final page is processed, like for example a conditional and so on.
>>
>>> Just some ideas for a more complete add-on.
>>> That would cover the "view" and "controller". The "model" are actually
>>> the
>>> beans via EL.
>>>
>>> Don't know if it really fits JSF or if there are better concepts - but
>>> that
>>> are almost all core features of ASP.NET MVC.
>>>
>>>
>>
>> I think what we are doing here instead is take the best we found from the
>> things we know that works. The challenge is integrate in a coherent way.
>>
>> For example, JSF as a component oriented framework has the concept
>> of clientIds associated with components. This is very helpful when you
>> move code from one place to another, because the generated ids on
>> the client side are updated properly. In an action oriented framework,
>> that's
>> a complete mess. The idea is preserve the JSF abstraction, that means
>> components that can be assembled in a hierarchical way, and that also
>> means this tree has a similar structure on the client.
>>
>> We can find workarounds. For example, bind the html generation to
>> a component, so we say "... generate an html fragment, but keep in mind
>> that chunk will be used in this component or a component with this
>> client id ..." So, the fragment is encapsulated in a jsf component that
>> implements NamingContainer and generates the specified clientId.
>> That could work. But I suppose it should be MyFaces Core implementation
>> specific, because we need to indicate to facelets the way how the ids
>> should be generated.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>>>
>>> 2014-04-23 13:40 GMT+02:00 Leonardo Uribe <lu4242@gmail.com>:
>>>
>>>> Hi
>>>>
>>>> 2014-04-23 11:54 GMT+02:00 Thomas Andraschko
>>>> <andraschko.thomas@gmail.com>:
>>>> TA> Hi,
>>>> TA>
>>>> TA> the most important question for me is actually:
>>>> TA>
>>>> TA> 1) How much should we really mix actions with facelets rendering?
>>>> TA>
>>>> TA> There are soooo many things to consider. As you already said in your
>>>> specs
>>>> TA> post: viewstate, windowid, viewscoped, ....
>>>> TA>
>>>>
>>>> I think the best way to deal with facelets rendering is use the standard
>>>> ajax.
>>>> I know in an action source framework people have to do the ajax stuff
>>>> "by hand", which means use the template framework to calculate a
>>>> fragment
>>>> of the response. That's a step back.
>>>>
>>>> Instead, this is for the case when you have a page in the client and you
>>>> need
>>>> to communicate with the server to get some information, but the page
>>>> structure
>>>> does not change. For example, an autocomplete component or a datatable
>>>> component. In that case, you only need the data usually in json format,
>>>> and
>>>> there is a javascript already in place to deal with that data and change
>>>> the
>>>> state of the client.
>>>>
>>>> The point is deal with the context in general. So if you send a POST
>>>> from
>>>> the
>>>> client, and you provide the windowid and the viewstate token, it should
>>>> be
>>>> processed, and the response should update the viewstate if necessary.
>>>> That's why we need some javascript on the client to wire things up.
>>>>
>>>> It could be possible a complex case, where we need a json response but
>>>> the response triggers an ajax update from the server. It can be done,
>>>> with
>>>> some javascript code.
>>>>
>>>> >
>>>> > For me the most important things are actually:
>>>> >
>>>> > 1) possibility to use a normal JSF lifecycle for the first GET request
>>>>
>>>> I agree with you, because in the first request you are just building the
>>>> view,
>>>> no special things there.
>>>>
>>>> > 2) allow action handling and custom response for POST actions
>>>>
>>>> Yes.
>>>>
>>>> > 3) normal action handling like in asp.net MVC + a EL util function to
>>>> > generate the action URL
>>>> >
>>>> >     $('#input').autocomplete({
>>>> >         source: "#{action('myBean', 'myAction', params...)}"
>>>> >     });
>>>> >
>>>> >     @Named("myBean")
>>>> >     @RequestScoped
>>>> >     public class MyBean {
>>>> >          @Action
>>>> >          // userId param with automatic converter lookup
>>>> >          public String myAction(String myUrlParam, User userId) {
>>>> >               return response;
>>>> >          }
>>>> >      }
>>>> >
>>>>
>>>>
>>>> Yes, that's one good point. I have seen too. It could be good to have
>>>> an EL function that renders the endpoint url automatically. In this
>>>> case,
>>>> you don't really care how the endpoind url is generated, as long as
>>>> when the javascript on the client side invokes the url you get the
>>>> pointed method executed.
>>>>
>>>> You could also want to bind the url to the component itself. The case is
>>>> you are writing a composite component and the component requires
>>>> the url, so you annotate a method in the base component class to
>>>> deal with this. In the GET case you don't have the view state, so the
>>>> component state is not restored, but in the POST case you can
>>>> submit the view state (for example calling a defined javascript
>>>> function)
>>>> and the code will execute an invokeOnComponent call on the server.
>>>>
>>>> > 4) Allow action rendering in in a normal lifecycle:
>>>> >
>>>> >    <ui:renderAction action="#{myBrean.myAction(bean.value, 1)}" />
>>>> >
>>>>
>>>> Could you please describe better this case? So you execute the action,
>>>> but the lifecycle goes on as usual?
>>>>
>>>> > 5) Action + facelets rendering -> question 1
>>>> >     Currently no idea how a integration should look like.
>>>> >
>>>> >
>>>>
>>>> I still don't have clear this point, but I can imagine you can return
>>>> XML from the server and parse it on the client somehow. Obviously
>>>> we need to find out how to do it.
>>>>
>>>> regards,
>>>>
>>>> Leonardo Uribe
>>>>
>>>>
>>>>
>>>> >
>>>> >
>>>> > 2014-04-22 18:24 GMT+02:00 Leonardo Uribe <lu4242@gmail.com>:
>>>> >
>>>> >> Hi
>>>> >>
>>>> >> In few word, the difficulty in this stuff is the context. If you
take
>>>> >> a
>>>> >> look
>>>> >> at the example proposed:
>>>> >>
>>>> >> @Named("myBean")
>>>> >> @RequestScoped
>>>> >> public class MyBean implements Serializable {
>>>> >>
>>>> >>     @RequestMapping(value = "/form1b.xhtml")
>>>> >>     public String form1() {
>>>> >>         String inputText1 = (String)
>>>> >> FacesContext.getCurrentInstance().
>>>> >>
>>>> >> getExternalContext().getRequestParameterMap().get("inputText1");
>>>> >>         setValue("We set inputText1 manually to - " + inputText1);
>>>> >>         return "/form1b.xhtml";
>>>> >>     }
>>>> >>
>>>> >> }
>>>> >>
>>>> >> To call the method you need to restore the context first of the
>>>> >> parent
>>>> >> bean and also there is a call to FacesContext.getCurrentInstance(),
>>>> >> so at that point it should be a valid FacesContext instance.
>>>> >>
>>>> >> In JSF 2.2 the lifecycle has 3 methods:
>>>> >>
>>>> >>                 //JSF 2.2: attach window
>>>> >>                 _lifecycle.attachWindow(facesContext);
>>>> >>                 // If this returns false, handle as follows:
>>>> >>                 // call
>>>> >> Lifecycle.execute(javax.faces.context.FacesContext)
>>>> >>                 _lifecycle.execute(facesContext);
>>>> >>                 // followed by
>>>> >> Lifecycle.render(javax.faces.context.FacesContext).
>>>> >>                 _lifecycle.render(facesContext);
>>>> >>
>>>> >> The idea is create a LifecycleWrapper that on lifecycle.execute()
>>>> >> implements a front controller pattern, doing the necessary steps
to
>>>> >> get the bean from the underlying CDI container and call the method.
>>>> >> If no method is called, continue as usual.
>>>> >>
>>>> >> The idea is not replicate all the features that an action source
>>>> >> framework
>>>> >> provides, just the important ones to deal with the cases we have
>>>> >> found
>>>> >> where this can be useful for JSF, or try to reutilize what's already
>>>> >> available in JSF. It will take some time to get it out, but I think
>>>> >> if
>>>> >> we can solve the use cases proposed, the final result will be
>>>> >> something
>>>> >> valuable.
>>>> >>
>>>> >> regards,
>>>> >>
>>>> >> Leonardo
>>>> >>
>>>> >> 2014-04-22 16:03 GMT+02:00 Karl Kildén <karl.kilden@gmail.com>:
>>>> >> > +1 To the idea
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > On 22 April 2014 15:53, Leonardo Uribe <lu4242@gmail.com>
wrote:
>>>> >> >>
>>>> >> >> Hi Thomas
>>>> >> >>
>>>> >> >> Yes, the idea is do something similar. The only thing we
need to
>>>> >> >> find
>>>> >> >> out is how to do it in a way that fits better with JSF.
>>>> >> >>
>>>> >> >> There are different people interested in this:
>>>> >> >>
>>>> >> >> - Some people wants to use JSF as a template engine, because
>>>> >> >> Facelets with JSF 2 Resource Handling and JSF 2.2 Resource
Library
>>>> >> >> Contracts can be an effective solution for server side
templating.
>>>> >> >>
>>>> >> >> - Some people want to use a JSF component library but they
need to
>>>> >> >> fill some gaps, like for example create a custom component
and on
>>>> >> >> the way they need to create a JSON endpoint. An mixed JSF-MVC
>>>> >> >> approach can be an effective solution.
>>>> >> >>
>>>> >> >> I think the mentioned example is just half of the solution.
That's
>>>> >> >> the reason why I'm gathering the use cases where this can
be
>>>> >> >> useful. The plan is write a prototype and discuss it, to
see how
>>>> >> >> far
>>>> >> >> can we go with this.
>>>> >> >>
>>>> >> >> regards,
>>>> >> >>
>>>> >> >> Leonardo
>>>> >> >>
>>>> >> >> 2014-04-22 15:21 GMT+02:00 Thomas Andraschko
>>>> >> >> <andraschko.thomas@gmail.com>:
>>>> >> >> > Hi Leo,
>>>> >> >> >
>>>> >> >> > +1 for the idea.
>>>> >> >> > Would it be similiar to:
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >
>>>> >> >> > https://weblogs.java.net/blog/mriem/archive/2014/01/13/jsf-tip-56-using-action-based-prototype-mojarra
>>>> >> >> > ?
>>>> >> >> >
>>>> >> >> > Regards,
>>>> >> >> > Thomas
>>>> >> >> >
>>>> >> >> >
>>>> >> >> > 2014-04-22 15:13 GMT+02:00 Leonardo Uribe <lu4242@gmail.com>:
>>>> >> >> >
>>>> >> >> >> Hi
>>>> >> >> >>
>>>> >> >> >> Over the time, with the new javascript libraries
out there that
>>>> >> >> >> makes
>>>> >> >> >> easier to make reliable code on the client side,
there are more
>>>> >> >> >> and
>>>> >> >> >> more people interested in an approach that can
take advantage
>>>> >> >> >> of
>>>> >> >> >> the good parts that JSF 2.2 already has, but without
get into
>>>> >> >> >> the
>>>> >> >> >> JSF
>>>> >> >> >> lifecycle complexities. It could be good if we
provide a new
>>>> >> >> >> module
>>>> >> >> >> inside MyFaces Commons that allow to do things
like in Spring
>>>> >> >> >> MVC
>>>> >> >> >> or
>>>> >> >> >> JAX-RS but also integrated with JSF.
>>>> >> >> >>
>>>> >> >> >> For example:
>>>> >> >> >>
>>>> >> >> >> - Create a JSON response from a managed bean and
bind it to a
>>>> >> >> >> component
>>>> >> >> >> using javascript.
>>>> >> >> >> - Define REST endpoints into CDI beans.
>>>> >> >> >> - Provide javascript functions that can invoke
a JSF POST or a
>>>> >> >> >> GET.
>>>> >> >> >> ...
>>>> >> >> >>
>>>> >> >> >> I have sended already an email to the EG list
related to this
>>>> >> >> >> stuff,
>>>> >> >> >> indicating some use cases where this can be useful.
See:
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >> https://java.net/projects/javaserverfaces-spec-public/lists/users/archive/2014-04/message/5
>>>> >> >> >>
>>>> >> >> >> CASE 1: Autocomplete component
>>>> >> >> >> CASE 2: Captcha component
>>>> >> >> >> CASE 3: Excel/PDF/Text/CSV export
>>>> >> >> >> CASE 4: REST
>>>> >> >> >> CASE 5: Websockets
>>>> >> >> >>
>>>> >> >> >> The idea is create two things:
>>>> >> >> >>
>>>> >> >> >> - An extension from the JSF lifecycle.
>>>> >> >> >> - A javascript library that can be called from
the client side
>>>> >> >> >> to
>>>> >> >> >> invoke
>>>> >> >> >> JSF on the server.
>>>> >> >> >>
>>>> >> >> >> The final result will look similar to an action
source
>>>> >> >> >> framework,
>>>> >> >> >> some annotations that can be parsed to define
a controller
>>>> >> >> >> algorithm,
>>>> >> >> >> use JSF as template framework and CDI as the model.
>>>> >> >> >>
>>>> >> >> >> In these moments I'm trying to imagine what can
we do in this
>>>> >> >> >> case,
>>>> >> >> >> so
>>>> >> >> >> any suggestion or comment about what people feel
missing and in
>>>> >> >> >> that
>>>> >> >> >> sense needs to be done is most welcome.
>>>> >> >> >>
>>>> >> >> >> regards,
>>>> >> >> >>
>>>> >> >> >> Leonardo Uribe
>>>> >> >> >
>>>> >> >> >
>>>> >> >
>>>> >> >
>>>> >
>>>> >
>>>
>>>
>
>
>
>

Mime
View raw message