Grails 3 fields plugin generating form elements from a command object - grails-plugin

I am running grails 3.0.4 and I have a simple command object AdvanceCommand
I am trying to create a form for all the fields in the command object using f:all tag from fields plugin. But I get an error
[views/advance/create.gsp:35] [views/advance/create.gsp:30] Tag [all] currently only supports domain types
the documentation specifically mentions command objects so I am a bit confused. if this tag is not working how do I generate form elements for a command object?
This is a snippet from my controller
def create() {
respond new AdvanceCommand()
}
and this is my gsp
<g:form action="save">
<fieldset class="form">
<f:all bean="advanceCommand"/>
</fieldset>
<fieldset class="buttons">
<g:submitButton name="create" class="save" value="${message(code: 'default.button.create.label', default: 'Create')}" />
</fieldset>
</g:form>
PS in the source repo of field plugin the latest version is 1.5.1 but if I run plugin-info I get 2.0.3 and 1.5.x is not even mentioned. Am I using a different plugin ?
grails> plugin-info fields
| Plugin Info: fields
| Latest Version: 2.0.3
| All Versions: 2.0.0.M1,2.0.0,2.0.1,2.0.2,2.0.3
| Title: Fields Plugin
Customizable form-field rendering based on overrideable GSP template
* License: APACHE
* Documentation: https://grails-fields-plugin.github.io/grails-fields
* Issue Tracker: https://github.com/grails-fields-plugin/grails-fields/issues
* Source: https://github.com/grails-fields-plugin/grails-fields

It appears they have forked a fields plugin from 1.4 to support grails 3. New documentation and source repo.
There is a feature request to support non domain objects in <f:all>. so it looks like its not supported yet. Using <f:field> seems to be the only way out

Related

Freemarker reference theme.properties in template

I am very new to this and have to migrate an existing web app (that I do not know much about) to Weblogic (12.2.1.4). I had to upgrade the version of struts (2.0.11.2 --> 2.3.1) which also came with a newer version of Freemarker (2.3.8 --> 2.3.18).
The template directory has subdirectories for the different themes.
Under ajax for example I have a file theme.properties containing this line:
parent=xhtml
A head.ftl then contains this include:
<#include "/${parameters.templateDir}/${themeProperties.parent}/head.ftl" />
However this throws the following error in the browser:
The following has evaluated to null or missing:
==> themeProperties.parent [in template "template/ajax/head.ftl" at line 2, column 41]
I believe this was working on the old server.
Is there some new way or syntax to reference the content of that properties file?
It seems like replacing
${themeProperties.parent}
with
${parameters.expandTheme}
seems to work

How to resolve the conflict between 2 plugins created via Lightweight method in shopware?

I have created a plugin. There is a backend listing form my plugin. so I have done this by using vue.js (https://developers.shopware.com/developers-guide/lightweight-backend-modules/)
There are no issues with the first plugin.
I have created another plugin. this plugin also has backend listing. I have created layout.tpl in my plugins _base folder.
But the problem is the 2nd plugin also loading the layout.tpl of the first plugin.
How to resolve this issue?
I have cleared the cache. But no hope.
Finally, I have fixed this issue by adding the following line of code in the backend controller.
$this->get('Template')->setTemplateDir([]);
--------Function------
public function preDispatch() {
$this->get('Template')->setTemplateDir([]);
$this->get('template')->addTemplateDir(__DIR__ . '/../../Resources/views/');
}
you should always "prefix" your views directory with an additional directory named like your plugin. Like this: Resources/views/backend/my_plugin_name/layout.tpl
With this you should not have the problem that one plugin uses the other plugins template file.
Best regards from Schöppingen
Michael Telgmann

does dojo config support requirejs bundles

Does dojo config support requirejs bundles?
Introduced in RequireJS 2.1.10: allows configuring multiple module IDs to be found in another script. Example:
requirejs.config({
bundles: {
'primary': ['main', 'util', 'text', 'text!template.html'],
'secondary': ['text!secondary.html']
}
});
require(['util', 'text'], function(util, text) {
//The script for module ID 'primary' was loaded,
//and that script included the define()'d
//modules for 'util' and 'text'
});
That config states: modules 'main', 'util', 'text' and 'text!template.html' will be found by loading module ID 'primary'. Module 'text!secondary.html' can be found by loading module ID 'secondary'.
In Dojo 1.8 modules were converted to AMD format, however dojo uses some "special loader plugins" which are still in draft and could be not fully compatible with RequireJS. On RequireJS documentation it is suggested to use Dojo's AMD loader instead.
Related doc from Dojod bug tracker ticket 15616.
Please note in case you need to "build" your dojo application you should use dojo util and app.profile.js,where you can specific a list of modules to "bundle" there.
I would suggest to have a look at this dojo-boilerplate as starting point for your dojo build configuration: https://github.com/csnover/dojo-boilerplate
A useful resource on the dojo build can be also found here: https://dojotoolkit.org/reference-guide/1.10/build/

WSO2 Identity / How to Register XACML PIP Java Extension and its Claims

Scanning through the WSO2 documentation and several blogs, I found three different type of registry mechanisms to add new claims to a Java PIP module:
By use of setup file calledentitlement.properties and by adding of Java static properties for each variable as described in the
sample case from the WSO2 manual, see: Writing a Custom Policy Info Point;
By use of supportedAttributesIds.add as described in link How to write a PIP point for WSO2 IS;
By use of a setter method: public Set getSupportedIds() { Set<String> ids = new HashSet<String>(); ids.add("http://kmarket.com/id/role"); return ids; } as described in the Stackoverflow post How To Add User Defined Attribute in PIP Attribute User Store
Please instruct which of the three options is the updated and recommended solution for adding new fields produced by the lookup of external data sources executed by the Balana PIP as an extension of the "AttributeFinderModule" class.
I've also tested the code posted in this example and compiled it with Java 6 JDK, see source reference
How To Add User Defined Attribute in PIP Attribute User Store
After the restart, the WSO2 server continues to display the following error:
Error while loading entitlement policies. Exception occurred while trying to invoke service method getAllPolicies
The following error details are available. Please refer logs for more details.
org.apache.axis2.AxisFault: Exception occurred while trying to invoke service method getAllPolicies
at org.wso2.carbon.identity.entitlement.ui.client.EntitlementPolicyAdminServiceClient.handleException(EntitlementPolicyAdminServiceClient.java:478)
at org.wso2.carbon.identity.entitlement.ui.client.EntitlementPolicyAdminServiceClient.getAllPolicies(EntitlementPolicyAdminServiceClient.java:81)
at org.apache.jsp.entitlement.index_jsp._jspService(org.apache.jsp.entitlement.index_jsp:183)
when adding the extended AttributeFinder Java extension. Is this a known bug in the WSO2 server?
The first way is configurable, you don't need to rebuild and deploy the PIP when you want to add new attibute. You just have to add them to entitlement.properties file. and restart the IS.
In other two ways, you have to rebuild the PIP module for each attribute changes.
But, If you are going to add and attribute, you have to implement the logic for that too, so in that case going for last two ways also make sense.
I've replaced the KmarketPIPAttributeFinder program module by the latest version from the svn source repository (see link below) and compiled it. This solved the problem under WSO2 Identity Server Version 5 and the routine started to register the PIP attributes, now visible at the PDP extensions.
Download the latest code from: https://svn.wso2.org/repos/wso2/carbon/platform/trunk/components/identity/org.wso2.carbon.identity.samples.entitlement.pip/src/main/java/org/wso2/carbon/identity/samples/entitlement/pip/KmarketPIPAttributeFinder.java

Dojo AMD and portlet-client-model

I'm using Dojo 1.9.1 AMD with WebSphere 8 portlets and can't figure out how to continue to leverage the WebSphere mechanism for getting/setting user's portlet preferences. Prior to moving from pre-AMD Dojo (1.6) to Dojo 1.9.1 AMD, I was including at the top of some JSP files these lines:
<%# taglib uri="http://www.ibm.com/xmlns/prod/websphere/portal/v6.1/portlet-client-model"
prefix="portlet-client-model" %> <portlet:defineObjects/>
<portlet-client-model:init>
<portlet-client-model:require module="ibm.portal.xml.*"/>
<portlet-client-model:require module="ibm.portal.portlet.*"/>
</portlet-client-model:init>
which get converted/generated into these lines at run-time:
<script> if(typeof dojo=='undefined') {
document.writeln("<scr"+"ipt src='/wps/portal_dojo/v1.4.3/dojo/dojo.js' ></scr"+"ipt>");
} </script>
<script>dojo.require('ibm.portal.xml.xpath'); dojo.require('ibm.portal.xml.xslt');</script>
<script>dojo.require('ibm.portal.portlet.portlet');</script>
<script>if(typeof(ibmPortalConfig) == "undefined") {ibmPortalConfig = {contentHandlerURI: "/wps/mycontenthandler/urs/!ut/p/digest!q8eCn6qc7fl2VjdmXXlayA/nm/oid:wps.portal.root"};} else if(!ibmPortalConfig["contentHandlerURI"]) {ibmPortalConfig["contentHandlerURI"] = "/wps/mycontenthandler/urs/!ut/p/digest!q8eCn6qc7fl2VjdmXXlayA/nm/oid:wps.portal.root";} </script><div id='com.ibm.wps.web2.portlet.root.Z7_HHGGGIO0JGPN00AI72U5E530O2' style='display: none;'>/wps/mycontenthandler/urs/!ut/p/digest!q8eCn6qc7fl2VjdmXXlayA/pm/oid:--portletwindowid--#oid:Z6_HHGGGIO0JGPN00AI72U5E530G4</div>
<div id='com.ibm.wps.web2.portlet.preferences.Z7_HHGGGIO0JGPN00AI72U5E530O2' style='display: none;' pageid='Z6_HHGGGIO0JGPN00AI72U5E530G4' configid='Z3_HHGGGIO0JGPN00AI72U5E53085' editdefaultsid='Z5_HHGGGIO0JGPN00AI72U5E530O6'
></div>
<div id='com.ibm.wps.web2.portlet.user.Z7_HHGGGIO0JGPN00AI72U5E530O2' style='display: none;'>/wps/mycontenthandler/urs/!ut/p/digest!q8eCn6qc7fl2VjdmXXlayA/um/secure/currentuser/profile?expandRefs=true</div>
which then allowed me to use javascript for getting and setting user portlet preferences. When I try using this same technique with Dojo 1.9.1 AMD, the same code that is generated above causes a javascript error complaining that the "dojo.require" is not a function.
With the improved Dojo AMD, I no longer have any calls to "dojo.require" like I used to, so I haven't encountered this issue, but these WebSphere custom tags automatically generate "dojo.require" calls that are now failing.
Do I need to try to mix the old pre-AMD inclusion of dojo.js with the preferred AMD inclusion calls? Has anyone encountered this issue yet?
Any help is appreciated. Thanks.
Your main problem is that you're using an old taglib. If I look at the URL I see that you're using a v6.1 taglib, which uses Dojo 1.4.3 and that is obviously outdated. Try to replace the taglib with:
<%# taglib
uri="http://www.ibm.com/xmlns/prod/websphere/portal/v8.0/portlet-client-model"
prefix="portlet-client-model" %>
I suppose that should generate some more appropriate code, compatible with the latest releases. You will probably have to update some libraries on your classpath as well.
Also, if you're using WebSphere Portal 8, then only Dojo 1.7 is supported officially, so make sure you're not using different versions here. WebSphere Portal 8.5 supports Dojo 1.9 (uses 1.9.3 to be exactly), but from your question it was not clear if you're using v8 or v8.5.
If you want to change the Dojo configuration and set async: false, that's possible, but you will have to set it before dojo.js is loaded. That means you will have to edit theme.html and the localized themes (for example theme_en.html) to add the following content above the co:head dynamic content spot:
<script type="text/javascript">
dojoConfig = {
async: false
};
</script>
<link rel="dynamic-content" href="co:head">
Be careful though, if you set it, you might break something, I don't know if IBM has their own configuration that includes custom packages or not, but if they do and you're overriding that configuration, then it might lead to errors.