Quantcast

Creating a new archetype

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Creating a new archetype

ivangsa
Hi Matt

I've been working on a gwt implementation which I would be happy to
contribute when it's ready, if you like it of course..

Now I'm trying to generate the archetype for gwt, I'm starting out of
the spring archetype which I'm more familiar with..

So I copied the archetype and  edited the build.xml to remove unused
files, remove some java files that don't compile any more as they
don't have the required dependencies, move some property files to a
nested package..

the idea is to generate a gwt project as lean as possible, so users
don't get confused by unused files..

do you think it's a good idea to remove unused files and configs that
don't have a lot of use on a single page application like sitemesh
decorators, urlrewrite..


also on the archetypes/README.txt points out that some files in
archetypes projects are symlinks or svn external so they are better
edited somewhere else, I'm not sure how current this is or if I'm just
fine by copying one archetype as base line for the new one..

any pointer you may have about this or any other thing I would greatly
appreciate..

Thanks a lot

Cheers
ivan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Creating a new archetype

mraible
Administrator
Hello Ivan,

I would recommend you remove the files from the project itself, rather than do it when building the archetype.

The README.txt is outdated. I've updated it to have the following:

There are several archetypes in this directory that are used to create new
AppFuse-based projects. Almost all of the files in these archetypes are
copies of files in web/*. The only file that's different is src/pom.xml.

As far as excluding files that are in "common" from ending up in your project, I'd look at the maven-war-plugin's configuration. It's pretty easy to exclude files there.

Finally, I'd recommend integrating GWT into AppFuse Light first, that way it's more of a standalone project and doesn't get much from AppFuse except for the backend.

Please let me know if you have any additional questions.

Thanks!

Matt

On Feb 23, 2013, at 2:56 AM, Ivan Garcia Sainz-Aja <[hidden email]> wrote:

> Hi Matt
>
> I've been working on a gwt implementation which I would be happy to
> contribute when it's ready, if you like it of course..
>
> Now I'm trying to generate the archetype for gwt, I'm starting out of
> the spring archetype which I'm more familiar with..
>
> So I copied the archetype and  edited the build.xml to remove unused
> files, remove some java files that don't compile any more as they
> don't have the required dependencies, move some property files to a
> nested package..
>
> the idea is to generate a gwt project as lean as possible, so users
> don't get confused by unused files..
>
> do you think it's a good idea to remove unused files and configs that
> don't have a lot of use on a single page application like sitemesh
> decorators, urlrewrite..
>
>
> also on the archetypes/README.txt points out that some files in
> archetypes projects are symlinks or svn external so they are better
> edited somewhere else, I'm not sure how current this is or if I'm just
> fine by copying one archetype as base line for the new one..
>
> any pointer you may have about this or any other thing I would greatly
> appreciate..
>
> Thanks a lot
>
> Cheers
> ivan

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Creating a new archetype

ivangsa
Hi Matt

thanks for your help,

I didn't thought of Appfuse Light to integrate first and it would
probably have been an easier path..

anyway, it was fun to implement all the functionality that there is in
Appfuse just the way it is

It's still work in progress but it has already most of Appfuse functionality..

If you want to give it a try

https://github.com/ivangsa/appfuse.git

(the quickest way to have a go would be
web/gwt> mvn -P gwtDebug -Dgwt.inplace=true jetty:run

at the moment it still requires this fork of gwt-bootstrap to be compiled first
https://github.com/ivangsa/gwt-bootstrap.git


It needs a lot of testing yet but it's getting quite there

thanks again for you help!

I will let you know if I have any other question.

Cheers!
ivan

On 23 February 2013 19:42, Matt Raible <[hidden email]> wrote:

> Hello Ivan,
>
> I would recommend you remove the files from the project itself, rather than do it when building the archetype.
>
> The README.txt is outdated. I've updated it to have the following:
>
> There are several archetypes in this directory that are used to create new
> AppFuse-based projects. Almost all of the files in these archetypes are
> copies of files in web/*. The only file that's different is src/pom.xml.
>
> As far as excluding files that are in "common" from ending up in your project, I'd look at the maven-war-plugin's configuration. It's pretty easy to exclude files there.
>
> Finally, I'd recommend integrating GWT into AppFuse Light first, that way it's more of a standalone project and doesn't get much from AppFuse except for the backend.
>
> Please let me know if you have any additional questions.
>
> Thanks!
>
> Matt
>
> On Feb 23, 2013, at 2:56 AM, Ivan Garcia Sainz-Aja <[hidden email]> wrote:
>
>> Hi Matt
>>
>> I've been working on a gwt implementation which I would be happy to
>> contribute when it's ready, if you like it of course..
>>
>> Now I'm trying to generate the archetype for gwt, I'm starting out of
>> the spring archetype which I'm more familiar with..
>>
>> So I copied the archetype and  edited the build.xml to remove unused
>> files, remove some java files that don't compile any more as they
>> don't have the required dependencies, move some property files to a
>> nested package..
>>
>> the idea is to generate a gwt project as lean as possible, so users
>> don't get confused by unused files..
>>
>> do you think it's a good idea to remove unused files and configs that
>> don't have a lot of use on a single page application like sitemesh
>> decorators, urlrewrite..
>>
>>
>> also on the archetypes/README.txt points out that some files in
>> archetypes projects are symlinks or svn external so they are better
>> edited somewhere else, I'm not sure how current this is or if I'm just
>> fine by copying one archetype as base line for the new one..
>>
>> any pointer you may have about this or any other thing I would greatly
>> appreciate..
>>
>> Thanks a lot
>>
>> Cheers
>> ivan
>



--
Enviado desde mi eZapato
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Creating a new archetype

mraible
Administrator
Hello Ivan,

I was able to successfully clone your fork of gwt-bootstrap and install it locally. However, when I run web/gwt as you suggest, I get a Loading... message and nothing happens. Looking in the console, I see:

http://localhost:8080/script/script.nocache.js 404 (Not Found)


On Feb 25, 2013, at 12:04 PM, Ivan Garcia Sainz-Aja <[hidden email]> wrote:

> Hi Matt
>
> thanks for your help,
>
> I didn't thought of Appfuse Light to integrate first and it would
> probably have been an easier path..
>
> anyway, it was fun to implement all the functionality that there is in
> Appfuse just the way it is
>
> It's still work in progress but it has already most of Appfuse functionality..
>
> If you want to give it a try
>
> https://github.com/ivangsa/appfuse.git
>
> (the quickest way to have a go would be
> web/gwt> mvn -P gwtDebug -Dgwt.inplace=true jetty:run
>
> at the moment it still requires this fork of gwt-bootstrap to be compiled first
> https://github.com/ivangsa/gwt-bootstrap.git
>
>
> It needs a lot of testing yet but it's getting quite there
>
> thanks again for you help!
>
> I will let you know if I have any other question.
>
> Cheers!
> ivan
>
> On 23 February 2013 19:42, Matt Raible <[hidden email]> wrote:
>> Hello Ivan,
>>
>> I would recommend you remove the files from the project itself, rather than do it when building the archetype.
>>
>> The README.txt is outdated. I've updated it to have the following:
>>
>> There are several archetypes in this directory that are used to create new
>> AppFuse-based projects. Almost all of the files in these archetypes are
>> copies of files in web/*. The only file that's different is src/pom.xml.
>>
>> As far as excluding files that are in "common" from ending up in your project, I'd look at the maven-war-plugin's configuration. It's pretty easy to exclude files there.
>>
>> Finally, I'd recommend integrating GWT into AppFuse Light first, that way it's more of a standalone project and doesn't get much from AppFuse except for the backend.
>>
>> Please let me know if you have any additional questions.
>>
>> Thanks!
>>
>> Matt
>>
>> On Feb 23, 2013, at 2:56 AM, Ivan Garcia Sainz-Aja <[hidden email]> wrote:
>>
>>> Hi Matt
>>>
>>> I've been working on a gwt implementation which I would be happy to
>>> contribute when it's ready, if you like it of course..
>>>
>>> Now I'm trying to generate the archetype for gwt, I'm starting out of
>>> the spring archetype which I'm more familiar with..
>>>
>>> So I copied the archetype and  edited the build.xml to remove unused
>>> files, remove some java files that don't compile any more as they
>>> don't have the required dependencies, move some property files to a
>>> nested package..
>>>
>>> the idea is to generate a gwt project as lean as possible, so users
>>> don't get confused by unused files..
>>>
>>> do you think it's a good idea to remove unused files and configs that
>>> don't have a lot of use on a single page application like sitemesh
>>> decorators, urlrewrite..
>>>
>>>
>>> also on the archetypes/README.txt points out that some files in
>>> archetypes projects are symlinks or svn external so they are better
>>> edited somewhere else, I'm not sure how current this is or if I'm just
>>> fine by copying one archetype as base line for the new one..
>>>
>>> any pointer you may have about this or any other thing I would greatly
>>> appreciate..
>>>
>>> Thanks a lot
>>>
>>> Cheers
>>> ivan
>>
>
>
>
> --
> Enviado desde mi eZapato

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Creating a new archetype

ivangsa
sorry I forgot to add gwt:compile to the command:

 mvn -P gwtDebug -Dgwt.inplace=true gwt:compile jetty:run

it should compile the module to src/main/webapp/script/

On 25 February 2013 20:57, Matt Raible <[hidden email]> wrote:

> Hello Ivan,
>
> I was able to successfully clone your fork of gwt-bootstrap and install it locally. However, when I run web/gwt as you suggest, I get a Loading... message and nothing happens. Looking in the console, I see:
>
> http://localhost:8080/script/script.nocache.js 404 (Not Found)
>
>
> On Feb 25, 2013, at 12:04 PM, Ivan Garcia Sainz-Aja <[hidden email]> wrote:
>
>> Hi Matt
>>
>> thanks for your help,
>>
>> I didn't thought of Appfuse Light to integrate first and it would
>> probably have been an easier path..
>>
>> anyway, it was fun to implement all the functionality that there is in
>> Appfuse just the way it is
>>
>> It's still work in progress but it has already most of Appfuse functionality..
>>
>> If you want to give it a try
>>
>> https://github.com/ivangsa/appfuse.git
>>
>> (the quickest way to have a go would be
>> web/gwt> mvn -P gwtDebug -Dgwt.inplace=true jetty:run
>>
>> at the moment it still requires this fork of gwt-bootstrap to be compiled first
>> https://github.com/ivangsa/gwt-bootstrap.git
>>
>>
>> It needs a lot of testing yet but it's getting quite there
>>
>> thanks again for you help!
>>
>> I will let you know if I have any other question.
>>
>> Cheers!
>> ivan
>>
>> On 23 February 2013 19:42, Matt Raible <[hidden email]> wrote:
>>> Hello Ivan,
>>>
>>> I would recommend you remove the files from the project itself, rather than do it when building the archetype.
>>>
>>> The README.txt is outdated. I've updated it to have the following:
>>>
>>> There are several archetypes in this directory that are used to create new
>>> AppFuse-based projects. Almost all of the files in these archetypes are
>>> copies of files in web/*. The only file that's different is src/pom.xml.
>>>
>>> As far as excluding files that are in "common" from ending up in your project, I'd look at the maven-war-plugin's configuration. It's pretty easy to exclude files there.
>>>
>>> Finally, I'd recommend integrating GWT into AppFuse Light first, that way it's more of a standalone project and doesn't get much from AppFuse except for the backend.
>>>
>>> Please let me know if you have any additional questions.
>>>
>>> Thanks!
>>>
>>> Matt
>>>
>>> On Feb 23, 2013, at 2:56 AM, Ivan Garcia Sainz-Aja <[hidden email]> wrote:
>>>
>>>> Hi Matt
>>>>
>>>> I've been working on a gwt implementation which I would be happy to
>>>> contribute when it's ready, if you like it of course..
>>>>
>>>> Now I'm trying to generate the archetype for gwt, I'm starting out of
>>>> the spring archetype which I'm more familiar with..
>>>>
>>>> So I copied the archetype and  edited the build.xml to remove unused
>>>> files, remove some java files that don't compile any more as they
>>>> don't have the required dependencies, move some property files to a
>>>> nested package..
>>>>
>>>> the idea is to generate a gwt project as lean as possible, so users
>>>> don't get confused by unused files..
>>>>
>>>> do you think it's a good idea to remove unused files and configs that
>>>> don't have a lot of use on a single page application like sitemesh
>>>> decorators, urlrewrite..
>>>>
>>>>
>>>> also on the archetypes/README.txt points out that some files in
>>>> archetypes projects are symlinks or svn external so they are better
>>>> edited somewhere else, I'm not sure how current this is or if I'm just
>>>> fine by copying one archetype as base line for the new one..
>>>>
>>>> any pointer you may have about this or any other thing I would greatly
>>>> appreciate..
>>>>
>>>> Thanks a lot
>>>>
>>>> Cheers
>>>> ivan
>>>
>>
>>
>>
>> --
>> Enviado desde mi eZapato
>



--
Enviado desde mi eZapato
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Creating a new archetype

mraible
Administrator
That worked and I was able to run the project and browse around. First of all - nice work!

Secondly, from briefly browsing around the project, it seems there's a lot of Java classes in the project. Are all of these necessary? How many classes/files does it take to add CRUD for a new entity?

Here's a cloc report on the various web frameworks in AppFuse (based on your project, not sure when you last pulled from master). I'm sure these reports could be adjusted to be more accurate, but I believe they give a good general overview.


And here's some graphs to see it visually. 



On Feb 25, 2013, at 1:07 PM, Ivan Garcia Sainz-Aja <[hidden email]> wrote:

sorry I forgot to add gwt:compile to the command:

mvn -P gwtDebug -Dgwt.inplace=true gwt:compile jetty:run

it should compile the module to src/main/webapp/script/

On 25 February 2013 20:57, Matt Raible <[hidden email]> wrote:
Hello Ivan,

I was able to successfully clone your fork of gwt-bootstrap and install it locally. However, when I run web/gwt as you suggest, I get a Loading... message and nothing happens. Looking in the console, I see:

http://localhost:8080/script/script.nocache.js 404 (Not Found)


On Feb 25, 2013, at 12:04 PM, Ivan Garcia Sainz-Aja <[hidden email]> wrote:

Hi Matt

thanks for your help,

I didn't thought of Appfuse Light to integrate first and it would
probably have been an easier path..

anyway, it was fun to implement all the functionality that there is in
Appfuse just the way it is

It's still work in progress but it has already most of Appfuse functionality..

If you want to give it a try

https://github.com/ivangsa/appfuse.git

(the quickest way to have a go would be
web/gwt> mvn -P gwtDebug -Dgwt.inplace=true jetty:run

at the moment it still requires this fork of gwt-bootstrap to be compiled first
https://github.com/ivangsa/gwt-bootstrap.git


It needs a lot of testing yet but it's getting quite there

thanks again for you help!

I will let you know if I have any other question.

Cheers!
ivan

On 23 February 2013 19:42, Matt Raible <[hidden email]> wrote:
Hello Ivan,

I would recommend you remove the files from the project itself, rather than do it when building the archetype.

The README.txt is outdated. I've updated it to have the following:

There are several archetypes in this directory that are used to create new
AppFuse-based projects. Almost all of the files in these archetypes are
copies of files in web/*. The only file that's different is src/pom.xml.

As far as excluding files that are in "common" from ending up in your project, I'd look at the maven-war-plugin's configuration. It's pretty easy to exclude files there.

Finally, I'd recommend integrating GWT into AppFuse Light first, that way it's more of a standalone project and doesn't get much from AppFuse except for the backend.

Please let me know if you have any additional questions.

Thanks!

Matt

On Feb 23, 2013, at 2:56 AM, Ivan Garcia Sainz-Aja <[hidden email]> wrote:

Hi Matt

I've been working on a gwt implementation which I would be happy to
contribute when it's ready, if you like it of course..

Now I'm trying to generate the archetype for gwt, I'm starting out of
the spring archetype which I'm more familiar with..

So I copied the archetype and  edited the build.xml to remove unused
files, remove some java files that don't compile any more as they
don't have the required dependencies, move some property files to a
nested package..

the idea is to generate a gwt project as lean as possible, so users
don't get confused by unused files..

do you think it's a good idea to remove unused files and configs that
don't have a lot of use on a single page application like sitemesh
decorators, urlrewrite..


also on the archetypes/README.txt points out that some files in
archetypes projects are symlinks or svn external so they are better
edited somewhere else, I'm not sure how current this is or if I'm just
fine by copying one archetype as base line for the new one..

any pointer you may have about this or any other thing I would greatly
appreciate..

Thanks a lot

Cheers
ivan




--
Enviado desde mi eZapato




--
Enviado desde mi eZapato

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Creating a new archetype

ivangsa

you are right that's a lot of files, and lines of code..


I would say that all of it is required code, I don't see anything that is not there for a good (and simple) reason..
but those metrics did strike me..


well, to implement CRUD to a new entity..
lets say a Person entity, and that all server side code required is covered by the PersonManager (e.g. no server processing, email notification..)

it would take about 12 new files :

PersonProxy: java interface representing getters and setter of the information to be send over the wire
PersonSearchCriteriaProxy: getters and setter for search fields (not really required)
PersonLocator.java: load/persist methods for server side gwt, it would just delegate on PersonManager
PersonRequest.java: remote interface for RequestFactory, analog to Async remote interfaces, same method names as PersonManager

4 files for each screen:

- Edit|Search Activity
- Edit|Search View Interface
- Edit|Search ViewImpl (this is where work is)
- Edit|Search Xml Template (this is where work is)

for CRUD it would not require Edit|Search Place as it could reuse EditEntityPlace|SearchEntityPlace..


Then it would require to add configuration entries to this other files:

- ApplicationActivityMapper : to map place -> activity
- ApplicationPlaceHistoryMapper: to map place -> history token
- ApplicationMenu: an entry into the menu tree
- ApplicationRequestFactory: factory method for PersonRequest
- ApplicationViewFactory: map view interface -> view impl
- ApplicationProxyFactory: add method to an interface to allow serialization of search criteria as bookmarkable history tokens




It's a lot of code, but just the java code to implement User's screens edit/profile/signup (which is mostly one action/one view) it takes about 700 loc which is more than a half of all code required in JSF or Struts

it is something to think about, but it's what it took.. (plus then the xml templates)


On 25 February 2013 22:12, Matt Raible <[hidden email]> wrote:
That worked and I was able to run the project and browse around. First of all - nice work!

Secondly, from briefly browsing around the project, it seems there's a lot of Java classes in the project. Are all of these necessary? How many classes/files does it take to add CRUD for a new entity?

Here's a cloc report on the various web frameworks in AppFuse (based on your project, not sure when you last pulled from master). I'm sure these reports could be adjusted to be more accurate, but I believe they give a good general overview.


And here's some graphs to see it visually. 



On Feb 25, 2013, at 1:07 PM, Ivan Garcia Sainz-Aja <[hidden email]> wrote:

sorry I forgot to add gwt:compile to the command:

mvn -P gwtDebug -Dgwt.inplace=true gwt:compile jetty:run

it should compile the module to src/main/webapp/script/

On 25 February 2013 20:57, Matt Raible <[hidden email]> wrote:
Hello Ivan,

I was able to successfully clone your fork of gwt-bootstrap and install it locally. However, when I run web/gwt as you suggest, I get a Loading... message and nothing happens. Looking in the console, I see:

http://localhost:8080/script/script.nocache.js 404 (Not Found)


On Feb 25, 2013, at 12:04 PM, Ivan Garcia Sainz-Aja <[hidden email]> wrote:

Hi Matt

thanks for your help,

I didn't thought of Appfuse Light to integrate first and it would
probably have been an easier path..

anyway, it was fun to implement all the functionality that there is in
Appfuse just the way it is

It's still work in progress but it has already most of Appfuse functionality..

If you want to give it a try

https://github.com/ivangsa/appfuse.git

(the quickest way to have a go would be
web/gwt> mvn -P gwtDebug -Dgwt.inplace=true jetty:run

at the moment it still requires this fork of gwt-bootstrap to be compiled first
https://github.com/ivangsa/gwt-bootstrap.git


It needs a lot of testing yet but it's getting quite there

thanks again for you help!

I will let you know if I have any other question.

Cheers!
ivan

On 23 February 2013 19:42, Matt Raible <[hidden email]> wrote:
Hello Ivan,

I would recommend you remove the files from the project itself, rather than do it when building the archetype.

The README.txt is outdated. I've updated it to have the following:

There are several archetypes in this directory that are used to create new
AppFuse-based projects. Almost all of the files in these archetypes are
copies of files in web/*. The only file that's different is src/pom.xml.

As far as excluding files that are in "common" from ending up in your project, I'd look at the maven-war-plugin's configuration. It's pretty easy to exclude files there.

Finally, I'd recommend integrating GWT into AppFuse Light first, that way it's more of a standalone project and doesn't get much from AppFuse except for the backend.

Please let me know if you have any additional questions.

Thanks!

Matt

On Feb 23, 2013, at 2:56 AM, Ivan Garcia Sainz-Aja <[hidden email]> wrote:

Hi Matt

I've been working on a gwt implementation which I would be happy to
contribute when it's ready, if you like it of course..

Now I'm trying to generate the archetype for gwt, I'm starting out of
the spring archetype which I'm more familiar with..

So I copied the archetype and  edited the build.xml to remove unused
files, remove some java files that don't compile any more as they
don't have the required dependencies, move some property files to a
nested package..

the idea is to generate a gwt project as lean as possible, so users
don't get confused by unused files..

do you think it's a good idea to remove unused files and configs that
don't have a lot of use on a single page application like sitemesh
decorators, urlrewrite..


also on the archetypes/README.txt points out that some files in
archetypes projects are symlinks or svn external so they are better
edited somewhere else, I'm not sure how current this is or if I'm just
fine by copying one archetype as base line for the new one..

any pointer you may have about this or any other thing I would greatly
appreciate..

Thanks a lot

Cheers
ivan




--
Enviado desde mi eZapato




--
Enviado desde mi eZapato




--
Enviado desde mi eZapato
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Creating a new archetype

mraible
Administrator
One enhancement I'd like to see is to use JSON for the server (possibly re-using existing REST services) rather than GWT's proxy mechanism. I did this back in 2009 when I used GWT and it worked pretty well. It also gives us the advantage of leveraging our API for other JS clients (e.g. AngularJS). 


We could also use RestyGWT to implement this:


For everything else, I'm guessing there's a way to generify things and allow base classes to take care of most of the logic.

On Feb 25, 2013, at 4:34 PM, Ivan Garcia Sainz-Aja <[hidden email]> wrote:


you are right that's a lot of files, and lines of code..


I would say that all of it is required code, I don't see anything that is not there for a good (and simple) reason..
but those metrics did strike me..


well, to implement CRUD to a new entity..
lets say a Person entity, and that all server side code required is covered by the PersonManager (e.g. no server processing, email notification..)

it would take about 12 new files :

PersonProxy: java interface representing getters and setter of the information to be send over the wire
PersonSearchCriteriaProxy: getters and setter for search fields (not really required)
PersonLocator.java: load/persist methods for server side gwt, it would just delegate on PersonManager
PersonRequest.java: remote interface for RequestFactory, analog to Async remote interfaces, same method names as PersonManager

4 files for each screen:

- Edit|Search Activity
- Edit|Search View Interface
- Edit|Search ViewImpl (this is where work is)
- Edit|Search Xml Template (this is where work is)

for CRUD it would not require Edit|Search Place as it could reuse EditEntityPlace|SearchEntityPlace..


Then it would require to add configuration entries to this other files:

- ApplicationActivityMapper : to map place -> activity
- ApplicationPlaceHistoryMapper: to map place -> history token
- ApplicationMenu: an entry into the menu tree
- ApplicationRequestFactory: factory method for PersonRequest
- ApplicationViewFactory: map view interface -> view impl
- ApplicationProxyFactory: add method to an interface to allow serialization of search criteria as bookmarkable history tokens




It's a lot of code, but just the java code to implement User's screens edit/profile/signup (which is mostly one action/one view) it takes about 700 loc which is more than a half of all code required in JSF or Struts

it is something to think about, but it's what it took.. (plus then the xml templates)


On 25 February 2013 22:12, Matt Raible <[hidden email]> wrote:
That worked and I was able to run the project and browse around. First of all - nice work!

Secondly, from briefly browsing around the project, it seems there's a lot of Java classes in the project. Are all of these necessary? How many classes/files does it take to add CRUD for a new entity?

Here's a cloc report on the various web frameworks in AppFuse (based on your project, not sure when you last pulled from master). I'm sure these reports could be adjusted to be more accurate, but I believe they give a good general overview.


And here's some graphs to see it visually. 

<img src="x-msg://2797/" height="480" width="612">
<img src="x-msg://2797/" height="480" width="609">


On Feb 25, 2013, at 1:07 PM, Ivan Garcia Sainz-Aja <[hidden email]> wrote:

sorry I forgot to add gwt:compile to the command:

mvn -P gwtDebug -Dgwt.inplace=true gwt:compile jetty:run

it should compile the module to src/main/webapp/script/

On 25 February 2013 20:57, Matt Raible <[hidden email]> wrote:
Hello Ivan,

I was able to successfully clone your fork of gwt-bootstrap and install it locally. However, when I run web/gwt as you suggest, I get a Loading... message and nothing happens. Looking in the console, I see:

http://localhost:8080/script/script.nocache.js 404 (Not Found)


On Feb 25, 2013, at 12:04 PM, Ivan Garcia Sainz-Aja <[hidden email]> wrote:

Hi Matt

thanks for your help,

I didn't thought of Appfuse Light to integrate first and it would
probably have been an easier path..

anyway, it was fun to implement all the functionality that there is in
Appfuse just the way it is

It's still work in progress but it has already most of Appfuse functionality..

If you want to give it a try

https://github.com/ivangsa/appfuse.git

(the quickest way to have a go would be
web/gwt> mvn -P gwtDebug -Dgwt.inplace=true jetty:run

at the moment it still requires this fork of gwt-bootstrap to be compiled first
https://github.com/ivangsa/gwt-bootstrap.git


It needs a lot of testing yet but it's getting quite there

thanks again for you help!

I will let you know if I have any other question.

Cheers!
ivan

On 23 February 2013 19:42, Matt Raible <[hidden email]> wrote:
Hello Ivan,

I would recommend you remove the files from the project itself, rather than do it when building the archetype.

The README.txt is outdated. I've updated it to have the following:

There are several archetypes in this directory that are used to create new
AppFuse-based projects. Almost all of the files in these archetypes are
copies of files in web/*. The only file that's different is src/pom.xml.

As far as excluding files that are in "common" from ending up in your project, I'd look at the maven-war-plugin's configuration. It's pretty easy to exclude files there.

Finally, I'd recommend integrating GWT into AppFuse Light first, that way it's more of a standalone project and doesn't get much from AppFuse except for the backend.

Please let me know if you have any additional questions.

Thanks!

Matt

On Feb 23, 2013, at 2:56 AM, Ivan Garcia Sainz-Aja <[hidden email]> wrote:

Hi Matt

I've been working on a gwt implementation which I would be happy to
contribute when it's ready, if you like it of course..

Now I'm trying to generate the archetype for gwt, I'm starting out of
the spring archetype which I'm more familiar with..

So I copied the archetype and  edited the build.xml to remove unused
files, remove some java files that don't compile any more as they
don't have the required dependencies, move some property files to a
nested package..

the idea is to generate a gwt project as lean as possible, so users
don't get confused by unused files..

do you think it's a good idea to remove unused files and configs that
don't have a lot of use on a single page application like sitemesh
decorators, urlrewrite..


also on the archetypes/README.txt points out that some files in
archetypes projects are symlinks or svn external so they are better
edited somewhere else, I'm not sure how current this is or if I'm just
fine by copying one archetype as base line for the new one..

any pointer you may have about this or any other thing I would greatly
appreciate..

Thanks a lot

Cheers
ivan




--
Enviado desde mi eZapato




--
Enviado desde mi eZapato




--
Enviado desde mi eZapato

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Creating a new archetype

ivangsa

I can have a look about publishing and consuming restful services


I knew you was going to ask for REST services, not only from this post http://raibledesigns.com/rd/entry/gwt_and_appfuse about appfuse + gwt but also because how you always rank REST support as a required feature when comparing web frameworks..

Can I ask you a question if you don't mind.. I understand the benefits of an restful api: interoperability, clients that only need to know how to talk hypermedia, intermediate caching, it's build on the basic idioms of the web, ...

but with how easy it is to expose the same java service interface using different mechanisms multiple times: JAX-WS, JAX-RS, Dwr, Gwt RPC, Gwt RequestFactory..
how important is it to publish and consume a restful api?



I bring this because there are two questions that always come across when serializing data over the network:
 * how would you manage serialization of nested entity relations and collections (possibly uninitialized or circular) 
 * and merging received data back to the entity

those are two questions that gwtRequestFactory solves quite nicely:

- it only sends over the wire nested properties you have asked for (e.g):
request.findUser("username").with("address", "roles").fire(callback); // it will send both relations
request.findUser("username").with("phoneNumber","email").fire(callback);// it will only send those two properties

- it only sends back to the server data that was actually modified in the client. Then it loads the persistent entities using its locator and merges only those properties that have been sent to the server.


I do not mind to much about the serialization mechanism behind gwt RequestFactory (I know it's json and its not restful) but I like some of its features (automatic data-binding with input widgets through the editor's framework, transparent JSR 303 validation on server calls, light weight network payload...)
I'm really more interested in those nice features that come with the RequestFactory than in using a trully restful api..

Anyway, behind the scenes it just uses a RequestBuilder to send and HTTP request to an url,
so I'm not sure how difficult would be to implement a generator for its RequestTransport to send the json payload to the required RESTful method..
this is something I will look into it

about JS Overly types, I understand we are talking about strongly typed objects, in the line of bean.getName() more than jsObject.get("name"), right?
(there are already methods in gwt to marshall/unmarshall json strings into any interface that extends ValueProxy so it should be easy..)


Regarding abstracting functionality to base classes I will try to make a Person CRUD demo, so many possibilities will probably show up

Thanks a lot Matt!

Cheers
ivan



On 26 February 2013 04:26, Matt Raible <[hidden email]> wrote:
One enhancement I'd like to see is to use JSON for the server (possibly re-using existing REST services) rather than GWT's proxy mechanism. I did this back in 2009 when I used GWT and it worked pretty well. It also gives us the advantage of leveraging our API for other JS clients (e.g. AngularJS). 


We could also use RestyGWT to implement this:


For everything else, I'm guessing there's a way to generify things and allow base classes to take care of most of the logic.

On Feb 25, 2013, at 4:34 PM, Ivan Garcia Sainz-Aja <[hidden email]> wrote:

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Creating a new archetype

mraible
Administrator
Comments inline below...

On Feb 26, 2013, at 11:07 AM, Ivan Garcia Sainz-Aja <[hidden email]> wrote:


I can have a look about publishing and consuming restful services


I knew you was going to ask for REST services, not only from this post http://raibledesigns.com/rd/entry/gwt_and_appfuse about appfuse + gwt but also because how you always rank REST support as a required feature when comparing web frameworks..

Can I ask you a question if you don't mind.. I understand the benefits of an restful api: interoperability, clients that only need to know how to talk hypermedia, intermediate caching, it's build on the basic idioms of the web, ...

but with how easy it is to expose the same java service interface using different mechanisms multiple times: JAX-WS, JAX-RS, Dwr, Gwt RPC, Gwt RequestFactory..
how important is it to publish and consume a restful api?

The publishing is easy, we've already done that. Consuming is important because it shows that we can use any client that understands JSON/XML to connect to our API. I think this is important for application development because, when I used GWT at Evite, we ended up ditching GWT (it's generated JS was too large for a fast site) and using raw HTML and jQuery. If we require a GWT-based backend for our GWT implementation, it forces developers to stick with GWT for the life of their application or rewrite the whole thing.


I bring this because there are two questions that always come across when serializing data over the network:
 * how would you manage serialization of nested entity relations and collections (possibly uninitialized or circular) 
 * and merging received data back to the entity

those are two questions that gwtRequestFactory solves quite nicely:

- it only sends over the wire nested properties you have asked for (e.g):
request.findUser("username").with("address", "roles").fire(callback); // it will send both relations
request.findUser("username").with("phoneNumber","email").fire(callback);// it will only send those two properties

- it only sends back to the server data that was actually modified in the client. Then it loads the persistent entities using its locator and merges only those properties that have been sent to the server.


I do not mind to much about the serialization mechanism behind gwt RequestFactory (I know it's json and its not restful) but I like some of its features (automatic data-binding with input widgets through the editor's framework, transparent JSR 303 validation on server calls, light weight network payload...)
I'm really more interested in those nice features that come with the RequestFactory than in using a trully restful api..

Anyway, behind the scenes it just uses a RequestBuilder to send and HTTP request to an url,
so I'm not sure how difficult would be to implement a generator for its RequestTransport to send the json payload to the required RESTful method..
this is something I will look into it

about JS Overly types, I understand we are talking about strongly typed objects, in the line of bean.getName() more than jsObject.get("name"), right?
(there are already methods in gwt to marshall/unmarshall json strings into any interface that extends ValueProxy so it should be easy..)


Regarding abstracting functionality to base classes I will try to make a Person CRUD demo, so many possibilities will probably show up

I think this would be great to see. I wrote up a blog post last night on your implementation. You can find it at the URL below:


I haven't received any comments or feedback on the blog post itself, but I did get a few responses on Twitter.


Cheers,

Matt


Thanks a lot Matt!

Cheers
ivan



On 26 February 2013 04:26, Matt Raible <[hidden email]> wrote:
One enhancement I'd like to see is to use JSON for the server (possibly re-using existing REST services) rather than GWT's proxy mechanism. I did this back in 2009 when I used GWT and it worked pretty well. It also gives us the advantage of leveraging our API for other JS clients (e.g. AngularJS). 


We could also use RestyGWT to implement this:


For everything else, I'm guessing there's a way to generify things and allow base classes to take care of most of the logic.

On Feb 25, 2013, at 4:34 PM, Ivan Garcia Sainz-Aja <[hidden email]> wrote:


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Creating a new archetype

ivangsa


On 8 March 2013 17:29, Matt Raible <[hidden email]> wrote:
Comments inline below...

On Feb 26, 2013, at 11:07 AM, Ivan Garcia Sainz-Aja <[hidden email]> wrote:


I can have a look about publishing and consuming restful services
...
how important is it to publish and consume a restful api?

The publishing is easy, we've already done that. Consuming is important because it shows that we can use any client that understands JSON/XML to connect to our API. I think this is important for application development because, when I used GWT at Evite, we ended up ditching GWT (it's generated JS was too large for a fast site) and using raw HTML and jQuery. If we require a GWT-based backend for our GWT implementation, it forces developers to stick with GWT for the life of their application or rewrite the whole thing.

ok, the same remote interface is already published by RequestFactory servlet and as a JAX-RS service with cxf so different clientes can connect to that (I have only read the wadl and tested the logout GET url cause I was being lazy but it's suppose to work..)

publishing the same interface twice using different api is not a problem, the problem is replacing the client implementation in gwt, where there is no reflection, you can not jut read annotations at runtime and callbacks api are simillar but are not the same so they can not be switched

but it you are ditching GWT then you are ditching the client all together..

Regarding abstracting functionality to base classes I will try to make a Person CRUD demo, so many possibilities will probably show up

I think this would be great to see. I wrote up a blog post last night on your implementation. You can find it at the URL below:

ok, I will take on this, let's see how it looks

(having 4 files per screen may look like a lot, but I have followed this same pattern in SWT development for some time and we have succesfully moved the same functionality from the desktop to web back and forth, cause activities and view interfaces do not import /almost/ nothing from the graphic toolkit
and when you need to know what some screen does you just open the view interface and see what data is being moved and which events may be triggered.
It really shows what it does..)
 



I haven't received any comments or feedback on the blog post itself, but I did get a few responses on Twitter.


Cheers,

Matt


Thanks a lot Matt!

Cheers
ivan



On 26 February 2013 04:26, Matt Raible <[hidden email]> wrote:
One enhancement I'd like to see is to use JSON for the server (possibly re-using existing REST services) rather than GWT's proxy mechanism. I did this back in 2009 when I used GWT and it worked pretty well. It also gives us the advantage of leveraging our API for other JS clients (e.g. AngularJS). 


We could also use RestyGWT to implement this:


For everything else, I'm guessing there's a way to generify things and allow base classes to take care of most of the logic.

On Feb 25, 2013, at 4:34 PM, Ivan Garcia Sainz-Aja <[hidden email]> wrote:





--
Enviado desde mi <eZapato>
Loading...