Your opinion about this framework and ideas to improve it

16 views
Skip to first unread message

plcoirier

unread,
Jul 6, 2009, 4:24:47 PM7/6/09
to Mvp4g
I start this message so that you can give your impression on this
framework. Does it answer your need? Is it easy enough to use?

It's still a beta version so if you have any ideas to improve it,
don't hesitate.

Thanks for any contribution you can make :)

webdizz

unread,
Aug 14, 2009, 5:25:19 PM8/14/09
to Mvp4g
Thanks a lot for your work!
I've decided to use mvp4g in the my new project.
I have some ideas may be they will be interesting and are deserved the
implementation.
- it will be nice to have more than 1 configuration file. when
project will be grow one configuration file will be not readable;
- also, I think, event types should be more type safety, for example
we can define it with EL, ${com.company.Events.EVT_NAME}, and decrease
opportunities for errors;
- also, due to Spring influence, I think it will be nice to have an
compile time annotation "@Autowired" for the fields to be injected
with *Async services;
- and the last one is ability to rewrite Async services path using
configurations. For example, we've configuring servlet for some URL
pattern differs from GWT application path, but have a convention for
service naming (e.g. service name is service interface name), so
provide some pattern to rewrite URL we can change default one. Pattern
can be like this one - pattern="${baseModuleURL}some_other_url", also
here we can provide ability to define URL with EL $
{com.app.ServiceInterface}.
Thanks.
P.S. if I'll have time I'll try to implement some of those ideas.

plcoirier

unread,
Aug 19, 2009, 10:53:53 AM8/19/09
to Mvp4g
On Aug 14, 11:25 pm, webdizz <webd...@gmail.com> wrote:
> Thanks a lot for your work!
> I've decided to use mvp4g in the my new project.
I'm glad you like it :)

> I have some ideas may be they will be interesting and are deserved the
> implementation.
> - it will be nice to have more than 1 configuration file. when
> project will be grow one configuration file will be not readable;
Good idea, I will add it to the issues.

> - also, I think, event types should be more type safety, for example
> we can define it with EL, ${com.company.Events.EVT_NAME}, and decrease
> opportunities for errors;
I'm not sure to see how you would use EL. Are you thinking of creating
a class for each event?
Maybe could you give an example?

> - also, due to Spring influence, I think it will be nice to have an
> compile time annotation "@Autowired" for the fields to be injected
> with *Async services;
Another good idea, I'm actually thinking of a version of Mvp4g using
annotations instead of the configuration file.

> - and the last one is ability to rewrite Async services path using
> configurations. For example, we've configuring servlet for some URL
> pattern differs from GWT application path, but have a convention for
> service naming (e.g. service name is service interface name), so
> provide some pattern to rewrite URL we can change default one. Pattern
> can be like this one - pattern="${baseModuleURL}some_other_url", also
> here we can provide ability to define URL with EL $
> {com.app.ServiceInterface}.
Would you have a common pattern for all services or each service will
have its own?
Maybe could you provide an example for this part too?

> Thanks.
> P.S. if I'll have time I'll try to implement some of those ideas.
Any help is welcome.

Thanks for your ideas

webdizz

unread,
Aug 19, 2009, 11:47:53 AM8/19/09
to mv...@googlegroups.com


2009/8/19 plcoirier <plco...@gmail.com>


On Aug 14, 11:25 pm, webdizz <webd...@gmail.com> wrote:
> Thanks a lot for your work!
> I've decided to use mvp4g in the my new project.
I'm glad you like it :)

> I have some ideas may be they will be interesting and are deserved the
> implementation.
>  - it will be nice to have more than 1 configuration file. when
> project will be grow one configuration file will be not readable;
Good idea, I will add it to the issues.

>  - also, I think, event types should be more type safety, for example
> we can define it with EL, ${com.company.Events.EVT_NAME}, and decrease
> opportunities for errors;
I'm not sure to see how you would use EL. Are you thinking of creating
a class for each event?
Maybe could you give an example?
I mean to use EL-like expressions to evaluate event type.
For example, on parsing conf file if we are getting EL-like expression we'll determine value for type from given constant from given class.

>  - also, due to Spring influence, I think it will be nice to have an
> compile time annotation "@Autowired" for the fields to be injected
> with *Async services;
Another good idea, I'm actually thinking of a version of Mvp4g using
annotations instead of the configuration file.
It would be nice. 

>  -  and the last one is ability to rewrite Async services path using
> configurations. For example, we've configuring servlet for some URL
> pattern differs from GWT application path, but have a convention for
> service naming (e.g. service name is service interface name), so
> provide some pattern to rewrite URL we can change default one. Pattern
> can be like this one - pattern="${baseModuleURL}some_other_url", also
> here we can provide ability to define URL with EL $
> {com.app.ServiceInterface}.
Would you have a common pattern for all services or each service will
have its own?
Yep, there is a common pattern and ability for service to have an own one. 

Maybe could you provide an example for this part too?
<services url="common_url_here"> 
 <service name="someService" class="org.company.SomeService" />
 <service name="someService1" class="org.company.SomeService1" url="some_another_url"/>
 <!-- if value of the "url" is is present we will create URL like ${common_url_here}/${some_another_url}/SomeService1 -->
 <!-- if value of the "url" is started from "/" or we create URL like ${some_another_url}/SomeService1 -->
 <!-- this approach will be helpful if we have separate module of services and GWT webapp will inherits this module -->
</services>


> Thanks.
> P.S. if I'll have time I'll try to implement some of those ideas.
Any help is welcome.
Thanks 


Thanks for your ideas




--
Best regards
Izzet Mustafayev

webdizz

unread,
Sep 18, 2009, 3:52:29 AM9/18/09
to Mvp4g
Hi, All.

Recently I've implemented some part of my thoughts for framework
improvements.
To the class com.mvp4g.util.Mvp4gGenerator to the initiating
ClassSourceFileComposerFactory
I added next line:

classFactory.addImport
("com.google.gwt.user.client.rpc.ServiceDefTarget");

To the class com.mvp4g.util.config.loader.ServicesLoader I changed
next variable declaration

static final String[] REQUIRED_ATTRIBUTES = { "name", "class",
"path" };

To the class com.mvp4g.util.Mvp4gConfigurationFileReader method
writeServices() a added next things


// override path to Async service if path
attribute present
if (null != service.getProperty("path")
&& !"".equals(service.getProperty("path"))) {
sourceWriter.println();
sourceWriter.println("// override path to Async service");
sourceWriter.print("((ServiceDefTarget)");
sourceWriter.print(name);
sourceWriter.print(")");
sourceWriter.print(".setServiceEntryPoint(");
sourceWriter.print("\"");
sourceWriter.print(service.getProperty("path"));
sourceWriter.print("\"");
sourceWriter.println(");");
sourceWriter.println();
}

Above changes provide ability to set following configuration
attributes to "services configuration"

<service name="simpleService" class="SimpleService" path="/gwt-
rpc/SimpleService" />

where declaration of the attribute "path" performs overriding of the
RPC service location. This more convenient if your services located on
different paths from your module. If you leave this attribute services
will have default configuration.

Thats all.

On Aug 19, 6:47 pm, webdizz <webd...@gmail.com> wrote:
> 2009/8/19 plcoirier <plcoir...@gmail.com>

plcoirier

unread,
Sep 22, 2009, 1:03:34 AM9/22/09
to Mvp4g
Thanks, I will add your changes for the 1.0 release (I created a new
issue 7)
> > Izzet Mustafayev- Hide quoted text -
>
> - Show quoted text -

webdizz

unread,
Oct 15, 2009, 4:55:15 AM10/15/09
to Mvp4g
Thanks for you work.
Working on my project I faced again with necessity to have several
config files but now it is more specific idea.
In GWT 2.x there is a feature to define code splitting. Separate
config files could be as modules, each file could contains module
specific views, presenters and etc. and each module should be
activated on specific event within "RunAsync" mode. After module
activation event triggered, module should be downloaded and module
init action should be performed.
Thereby we can decrease size of *.js files and application startup
time.
What do you think about this?

plcoirier

unread,
Oct 15, 2009, 10:10:50 AM10/15/09
to Mvp4g
I really like your idea.

I haven't looked at GWT 2.x and RunAsync mode yet so idk yet how you
would do that, maybe you already have some ideas on how to implement
it?

By the way, Mvp4g-1.0.0 has been released.

webdizz

unread,
Oct 16, 2009, 5:35:05 AM10/16/09
to mv...@googlegroups.com, plco...@gmail.com
In attach you can find preliminary implementation of the idea proposed in http://groups.google.com/group/mvp4g/msg/e403b4dd29a4776b and an example of usage based on TestMvp4g project.


On Oct 15, 2009 5:10pm, plcoirier <plco...@gmail.com> wrote:


> I really like your idea.



> I haven't looked at GWT 2.x and RunAsync mode yet so idk yet how you

> would do that, maybe you already have some ideas on how to implement

> it?


> By the way, Mvp4g-1.0.0 has been released.

test-mvp4g.zip
sources.zip

plcoirier

unread,
Oct 16, 2009, 4:23:53 PM10/16/09
to Mvp4g
Thanks, I'm going to look at GWT 2.x first to understand the RunAsync
mode and then I will look at your implementation.

On Oct 16, 11:35 am, webdizz <webd...@gmail.com> wrote:
> In attach you can find preliminary implementation of the idea proposed inhttp://groups.google.com/group/mvp4g/msg/e403b4dd29a4776band an example of
> usage based on *TestMvp4g* project.
>
> On Oct 15, 2009 5:10pm, plcoirier <plcoir...@gmail.com> wrote:
>
>
>
>
>
>
>
> > I really like your idea.
>
> > I haven't looked at GWT 2.x and RunAsync mode yet so idk yet how you
>
> > would do that, maybe you already have some ideas on how to implement
>
> > it?
>
> > By the way, Mvp4g-1.0.0 has been released.
>
> --
> Best regards
> Izzet Mustafayev
>
>  test-mvp4g.zip
> 1795KViewDownload
>
>  sources.zip
> 287KViewDownload- Hide quoted text -

webdizz

unread,
Oct 21, 2009, 6:01:40 AM10/21/09
to mv...@googlegroups.com
Hi, 
I have additional improvement. This improvement-proposal is consider with abilities to define alternative configuration file. This functionality will be helpful when your application requires separate GWT and mvp4g based admin panel (back-end) and you want to separate it from front-end part of application.
To provide this to your application you need to extend Mvp4gStarter interface and to define @com.mvp4g.client.Configuration annotation and to specify value as path to config file for annotation. Then you simply call GWT.create(YourExtendOfMvp4gSarter);
Example:
Configuration("alternative-mvp4g-config.xml")
public interface YourExtendOfMvp4gSarter extends Mvp4gStarter {}
Now your application will have to separate entry points with own configuration files.
Thanks in advance for your comments.
test-mvp4g.zip
sources.zip

Pierre

unread,
Oct 21, 2009, 2:15:48 PM10/21/09
to Mvp4g
I started a new message to continue the conversation about Mvp4g and
GWT 2.x (RunAyns feature). See http://groups.google.com/group/mvp4g/browse_thread/thread/2c80f33cc38b5f3f.

I think we may have a lot to say about it.

On Oct 21, 12:01 pm, webdizz <webd...@gmail.com> wrote:
> Hi,  I have additional improvement. This improvement-proposal is consider
> with abilities to define alternative configuration file. This functionality
> will be helpful when your application requires separate GWT and mvp4g based
> admin panel (back-end) and you want to separate it from front-end part of
> application.
> To provide this to your application you need to extend Mvp4gStarter
> interface and to define @com.mvp4g.client.Configuration annotation and to
> specify value as path to config file for annotation. Then you simply call
> GWT.create(YourExtendOfMvp4gSarter);
> Example:
> *Configuration("alternative-mvp4g-config.xml")*
> *public interface YourExtendOfMvp4gSarter extends Mvp4gStarter {}*
> Now your application will have to separate entry points with own
> configuration files.
> Thanks in advance for your comments.
>
>  test-mvp4g.zip
> 1870KViewDownload
>
>  sources.zip
> 288KViewDownload
Reply all
Reply to author
Forward
0 new messages