yasuflatland-lf / damascus Goto Github PK

In *LocalServiceImpl#getDateTimeFromRequest, this method should return alternative data instead of throwing an exception when no parameters for date found. Also in the exception, it needs to be printed on the console. The sample code is below.

    public Date getDateTimeFromRequest(PortletRequest request, String prefix) {
        int Year = ParamUtil.getInteger(request, prefix + "Year");
        int Month = ParamUtil.getInteger(request, prefix + "Month") + 1;
        int Day = ParamUtil.getInteger(request, prefix + "Day");
        int Hour = ParamUtil.getInteger(request, prefix + "Hour");
        int Minute = ParamUtil.getInteger(request, prefix + "Minute");
        int AmPm = ParamUtil.getInteger(request, prefix + "AmPm");

        if (AmPm == Calendar.PM) {
            Hour += 12;
        }

        LocalDateTime ldt;
		try {
			ldt = LocalDateTime.of(Year, Month, Day, Hour, Minute, 0);
		} catch (Throwable e) {
			e.printStackTrace();
			Date in = new Date();
			Instant instant = in.toInstant();
			return Date.from(instant);			
		}
		
        return Date.from(ldt.atZone(ZoneId.systemDefault()).toInstant());
    }

There is a typo mistake for Long field type: "primaly" instead of "primary".

Activity doesn't work properly

*-web switch would be preferable to be implemented when a user needs only services.

South Asia countries, they often use simple workflow rather than full blown functionality that Liferay has out of box.

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.

need to add something like as follows in *Portlet.java

	@Override
	protected void doDispatch(
			RenderRequest renderRequest, RenderResponse renderResponse)
		throws IOException, PortletException {

        renderRequest.setAttribute(DummyFactoryConfiguration.class.getName(), _dummyFactoryConfiguration);

		super.doDispatch(renderRequest, renderResponse);
	}

There is a missing template for liferay 7.1. Hope damascus can support 7.1.

see here

https://github.com/yasuflatland-lf/damascus/wiki/1.-Getting-Started

Because of bugs in generated portlet, Asset publisher portlet gets NPE when it displays records of the generated portet.

the path of configuration page is incorrect so the page gets error and nothing displayed.

I've seen more Windows users, Damascus should be tested on Windows. Add AppVeyor support.

Thank you for your contribution, @yoshikakoba! It's updated 933d610 and here

The templates in src/test/resources/templates directory (duplicated from src/main/resources/templates) seems not to be used.

Should we remove this directory?

A master validation is most required functionality. Similar like in XMLPortletfactory : http://www.xmlportletfactory.org/2-tables-master-and-validation

DateTime generate only Date field. Time field should be created too

Currently admin page and user page use same jsps. Admin pages should have a default UI layout.

When you creating a record and click the add button, The request seems to be sent 2 times somehow.

Generate Web Service API for each portlet created.

Create "View Detail" Functionality.

We already created this for 7.0 version, we need to customise so it support 7.1 version. Our team will upgrade it to 7.1 version, then will ask for pull request.

dlBrowse script exists when document media field doesn't exist. Should be removed when it's not necessarily.

Motivation

At a project, there's a case where a user wants to use Damascus as a service generator of their custom templates. In that case, users repeat a cycle to generate codes and fix templates accordingly. A functionally to assist the cycle efficiency will be beneficial not only for users but also Damascus contributors as well.

The idea of implementation

Replacement patterns

The default replacement patterns between template value and Keywords (model names, package names and directory names) should be generated in base.json file as optional fields at damascus -init command called.

The fields should be customizable as users may want to add custom patterns as well.

Master and Detail - One to Many relationship like the one in XMLPortletFactory :

http://www.xmlportletfactory.org/2-tables-master-and-detail

Not only implemented templates, if user customized templates are selectable, that'd be useful for system integrators to use Damascus as a service code generator.

On each portlet, there will be a button "Export Excel", that export portlet records to excel file. Similar that created in XMLPortletfactory : http://www.xmlportletfactory.org/export-to-excel

typo : *ConfigrationAction should be *ConfigurationAction

Create Server Side Validation

1st of all this is a great CRUD plugin for Liferay. Thanks for developing and contributing this.

This feature would be a great benefit : manage relations between entities.

Let us know how we could contribute for Damascus...

Create "Advanced Search" Functionality.

We already created this for 7.0 version, we need to customise so it support 7.1 version.

Hey @yasuflatland-lf , you should not generate settings.gradle , build.gradle and gradlew files (cause they are nested projects) and remove all plugin applying, cause liferay workspace plugin will apply them.

Hi,
great work here! I tried to customize templates to allow generation of an HTML Select input for one of my fields. Currently I added a bunch of fields in the customValue field of base.json. Currently they are:

"fieldXY": 3,
"fieldXYvalue1": "1",
"fieldXYlabel1" : "Option 1",
"fieldXYvalue2": "2",
"fieldXYlabel2" : "Option 2",
"fieldXYvalue3": "3",
"fieldXYlabel3" : "Option 3"

that I parse in the template as

<#if (field.type?string == "com.liferay.damascus.cli.json.fields.Integer" && application.customValue[field.name]?? ) >
  <aui:select name="${field.name}" disabled="false" label='<%=LanguageUtil.get(request, "${lowercaseModel}-${field.name?lower_case}") + requiredLabel%>'>
    <aui:option value="" label="Select a value"/>
    <#list 1..application.customValue[field.name]?number as optionIdx>
      <#assign optionvalue = application.customValue[field.name+"value"+optionIdx?string] />
      <#assign optionlabel = application.customValue[field.name+"label"+optionIdx?string] />
      <aui:option value="${optionvalue}" label="${optionlabel}"/>
    </#list>
  </aui:select>
</#if>

I saw that customValue is implemented as a Map<String, String> so it is a sort of key-value map. Maybe a Map<String, Object> could be better for having custom objects in base.json that can be used in templates.
So in base.json it could be:

"customValue" : {
       "fieldXY": {
            "items": [
                {value:1, label: "Option 1"},
                {value:2, label: "Option 2"},
                {value:3, label: "Option 3"}
          ]
         }
      }

Even better could be having a custom object in the field definition so that one can specify custom code based on field data.
So for an integer field in base.json it could be:

{
  "type": "com.liferay.damascus.cli.json.fields.Integer",
  "name": "fieldXY",
  "title": "Field Title",
  "required": "true" {
  "items": [
     {value:1, label: "Option 1"},
     {value:2, label: "Option 2"},
     {value:3, label: "Option 3"}
    ]
}

In service.xml, Damascus have Validation Exception class, but it includes "ValidationException" at the end of name. That causes of generating "TodoValidationExceptionException" class.

In the generated code, Document & Media button doesn't work on Firefox.

Since many functionalities are pre implemented in the templates, README that described details in *-service and *-web will be helpful for users.

It can be valuable to implement the generateActivity flag on asset element, for file base.json.

@yasuflatland-lf If you accept help for this task, I can implement the feature and send you a pull request.

It may be obvious, each validation method need to add error details messages in _errors field when it's invalid. Usage comments in the class comments area would be more user friendly.

aui:button-row must be outside of div.portlet-configuration-body-content.

The project name has 2 restrictions as below now

1. The project name must start from a capital alphabet letter
2. Hyphens are not allowed.

1 should be straight forward to resolve, but in terms of 2, service builder doesn't allow hyphens for the model / field name. Damascus utilize project name (a parameter after -init) for model / primary key field name for now, so they may need to be converted into other way, say camel case for example when a user run damascus -init

The current code is as below

<aui:input name="categories" type="assetCategories" />
<aui:input name="tags" type="assetTags" />

<liferay-ui:panel defaultState="closed" extended="<%=false%>"
    id="todoEntryAssetLinksPanel" persistState="<%=true%>"
    title="related-assets">
    <aui:fieldset>
        <liferay-ui:input-asset-links
            className="<%=Todo.class.getName()%>"
            classPK="<%=todo.getPrimaryKey()%>" />
    </aui:fieldset>
</liferay-ui:panel>

These need to be as follows

<aui:fieldset collapsed="<%= true %>" collapsible="<%= true %>" label="categorization">
    <aui:input name="categories" type="assetCategories" />

    <aui:input name="tags" type="assetTags" />
</aui:fieldset>

<aui:fieldset collapsed="<%= true %>" collapsible="<%= true %>" label="related-assets">
    <liferay-ui:input-asset-links
        className="<%= BlogsEntry.class.getName() %>"
        classPK="<%= entryId %>"
    />
</aui:fieldset>

As a developer, custom variables in templates to manage conditions is helpful. The expected use case is as follows

1. Define valuables in base.json (extend base.json structure)
2. Create custom templates and use those conditional values with Freemarker. Maybe storing those data into an associative array.

Please look for more detail in the gif attached.

Templates cache is never refreshed : if you build and install a new version of Damascus with modifications in template files, the template files stored in ${HOME}/.damascus/templates are never updated.

It can be valuable to implement the flags categories, discussion, ratings, tags and relatedAssets on asset element, for file base.json.

@yasuflatland-lf If you accept help for this task, I can implement the features and send you a pull request.

Hi,

I installed damascus with jpm as indicated in the wiki, but when I run it I get an AnnotationTypeMismatchException error.

I tried to compile it myself, same result as you can see below.

C:\...\damascus\build\libs>java -jar damascus.jar -init Todo -p todo
java.lang.annotation.AnnotationTypeMismatchException: Incorrectly typed data found for annotation element public abstract java.lang.Class[] com.beust.jcommander.Parameter.validateWith() (Found data of type class java.lang.Class[class com.liferay.damascus.cli.validators.ProjectNameValidator])
        at sun.reflect.annotation.AnnotationTypeMismatchExceptionProxy.generateException(Unknown Source)
        at sun.reflect.annotation.AnnotationInvocationHandler.invoke(Unknown Source)
        at com.sun.proxy.$Proxy2.validateWith(Unknown Source)
        at com.beust.jcommander.WrappedParameter.validateWith(WrappedParameter.java:55)
        at com.beust.jcommander.ParameterDescription.validateParameter(ParameterDescription.java:330)
        at com.beust.jcommander.ParameterDescription.addValue(ParameterDescription.java:233)
        at com.beust.jcommander.JCommander.processFixedArity(JCommander.java:895)
        at com.beust.jcommander.JCommander.processFixedArity(JCommander.java:870)
        at com.beust.jcommander.JCommander.parseValues(JCommander.java:721)
        at com.beust.jcommander.JCommander.parse(JCommander.java:340)
        at com.beust.jcommander.JCommander.parse(JCommander.java:319)
        at com.beust.jcommander.JCommander.<init>(JCommander.java:253)
        at com.liferay.damascus.cli.Damascus.run(Damascus.java:57)
        at com.liferay.damascus.cli.Damascus.main(Damascus.java:46)

I fixed it by using JCommander 1.71 (https://github.com/cbeust/jcommander/releases/tag/1.71)

-compile 'com.beust:jcommander:1.64'
+compile 'com.beust:jcommander:1.71'

Is there a reason why you rolled back to version 1.64 in commit bc62708#diff-c197962302397baf3a4cc36463dce5ea?

Since the last release, it seems that the minimal required versions of Liferay for generated code was higher than previously (now it seems to be Liferay 7.0 CE GA4 and Liferay DXP SP3).

It will be very valuable to add the minimal required versions to the readme file.

At Exception in *ActionCommand.java and *ServiceLocalImpl.java, the root error cause must be displayed on console because it's hard to debug without it.

In case where throwing a custom exception, log.error may be appropriate.