search

yasuflatland-lf / damascus

⚔️ CRUD boilerplate generator for Liferay DXP
https://yasuflatland-lf.github.io/damascus-doc/
GNU Lesser General Public License v3.0
51 stars 35 forks source link

Generate code for multiple entities in the same modules. #16

Closed slemarchand closed 7 years ago

slemarchand commented 7 years ago

For now, when we define several entities in our base.json file, we get 3 modules for each entity (*-api, *-service and *-web).

In my point of view, it would be more valuable to get 3 modules in total.

To be more concrete, consider the airline example project with entites Flight and Plane. With the current version of Damascus, the directory layout looks like this (and there is only 1 entity in each service.xml file) :

airline
|
|----Flight-api
|
|----Flight-service
|    |
|    |--- service.xml 
|
|----Flight-web
|
|----Plane-api
|
|----Plane-service
|    |
|    |--- service.xml
|
|----Plane-web

With the proposed evolution, the directory layout would look like that (and all the entities would be in the only service.xml file) :

airline
|
|----airline-api
|
|----airline-service
|    |
|    |--- service.xml
|
|----airline-web

@yasuflatland-lf : What is your feeling about that? If you agree I can implement this evolution and submit you a pull request.

yasuflatland-lf commented 7 years ago

Hi @slemarchand

I basically agree with your idea and thank you for bringing up this! We may need to take into account some aspects below.

  1. The sitemap design to include multiple models CRUD in one *-web How do you bundle multiple model's CRUD in one *-web? The top page of the generated portlet is now view.jsp, a record list of the model. Whereas it's pretty straight forward to connecting other pages for create / edit / view functionality. we need to take into account the layout of pages for multiple models.

  2. Model relations Having multiple models, you may usually have relations between each model with external keys at an actual project. Are you going to implement this part? If you do, how do you handle this?

  3. JSP folder structure You may want to create a sub directories for each model. This is my bad, I should have placed jsps under the model name folder. Say, you have flight, plane models, you might want to place each jsps as /flight/view.jsp /plane/view.jsp, e.g. Placing all jsps in a same directory would be pretty messy from maintainability standpoint later on.

For templates of Damascus, I have a reference implementation, SampleSB (https://github.com/yasuflatland-lf/SampleSB). Can you also fix the jsp folder structure of this repo too?

  1. Increasing complexity for upgrade / new feature addition For adding new features to the template or just following the latest version in future, say 7.1 or later, I'm bit afraid of the template getting too complex to add new features and upgrading for later version. I'd like know your thought on this too.
slemarchand commented 7 years ago

Hi @yasuflatland-lf,

Thanks for your feedback. See below my thoughts about the aspects you have mentionned.

  1. The sitemap design to include multiple models CRUD in one *-web How do you bundle multiple model's CRUD in one `*-web? The top page of the generated portlet is now view.jsp, a record list of the model. Whereas it's pretty straight forward to connecting other pages for create / edit / view functionality. we need to take into account the layout of pages for multiple models.

Within the scope of this issue (#16), I plan to keep the generated user interface as is. That is, there is still a dedicated portlet for each entity, but all portlets are grouped together in the same module.

There are many ways to improve the user interface, but I think it would be better to explore them in the context of dedicated issues.

  1. Model relations Having multiple models, you may usually have relations between each model with external keys at an actual project. Are you going to implement this part? If you do, how do you handle this?

I'm not going implement this part within the scope of the current issue (#16). I have in mind the need to manage relations between entities, but from my point of view, we should manage it a little later, with a dedicated issue.

2.JSP folder structure You may want to create a sub directories for each model. This is my bad, I should have placed jsps under the model name folder. Say, you have flight, plane models, you might want to place each jsps as /flight/view.jsp /plane/view.jsp, e.g. Placing all jsps in a same directory would be pretty messy from maintainability standpoint later on.

Creating such sub directories was my intention from the begining :-)

For templates of Damascus, I have a reference implementation, SampleSB (https://github.com/yasuflatland-lf/SampleSB). Can you also fix the jsp folder structure of this repo too?

No problem, I will submit a pull request for this repository.

  1. Increasing complexity for upgrade / new feature addition For adding new features to the template or just following the latest version in future, say 7.1 or later, I'm bit afraid of the template getting too complex to add new features and upgrading for later version. I'd like know your thought on this too.

Not sure to understand why you think that templates will become too complex due to this enhancement.

Maybe, it's because you think I will add a new flag in base.json to choose the bundling strategy between "dedicated modules for each model" and "all models in the same modules"? But I will not do that: my primary intention was to support only one bundling strategy ("all models in the same modules"). So, the templates will not be really more complex than for now.

yasuflatland-lf commented 7 years ago

Hi @slemarchand

Within the scope of this issue (#16), I plan to keep the generated user interface as is. That is, there is still a dedicated portlet for each entity, but all portlets are grouped together in the same module. There are many ways to improve the user interface, but I think it would be better to explore them in the context of dedicated issues.

Ok, I agree with leaving detailed user interface design up to the user.

I'm not going implement this part within the scope of the current issue (#16). I have in mind the need to manage relations between entities, but from my point of view, we should manage it a little later, with a dedicated issue.

Got it.

Creating such sub directories was my intention from the begining :-)

Ok! Sorry for bothering you this part. And thank you for fixing SampleSB, the reference implementation as well.

Not sure to understand why you think that templates will become too complex due to this enhancement. Maybe, it's because you think I will add a new flag in base.json to choose the bundling strategy between "dedicated modules for each model" and "all models in the same modules"? But I will not do that: my primary intention was to support only one bundling strategy ("all models in the same modules"). So, the templates will not be really more complex than for now.

I agree with your " one bundling strategy" and I could make sure that we are on the same page. Please go ahead the development. Thank you for your contributions, Sébastien!

slemarchand commented 7 years ago

Important notes about the implementation in PR #20: