Moqui Learning Data and resources

Resource Location:the string for the resource façade location is similar to how the URL is constructed: protocol, host, optional port, and file name. It supports the standard Java URL Protocol (HTTP HTTPS ftp jar file). Also supports some extended protocols:

1. classpath://Resources for Java Classpath
2. content://Resources for the content repository (JCR via Jackrabbit Client): The first element after the protocol prefix in the path is the name of the content warehouse, which is specified by the Repository.name attribute in the moqui XML configuration file.
3. component://the path relative to the location of the component. Regardless of where the component is located (file system, content warehouse, etc.)
4. dbresource://because of a virtual file system, the entity façade is persisted in the database through Moqui.resource.DbResource and dbresourcefile entities.

Other protocols can be accomplished by implementing the Org.moqui.context.ResourceReference interface and adding a resource-facade.resource-reference element to the Moqui XML configuration file. The protocols that have been supported are configured in the Moquidefaultconf.xml file. Working with Resourcesusing a resource in accordance with a supported protocol is to directly read text or binary content. Get text from a resource location using the Ec.resource.getLocationText (String Location,boolean cache) method. Gets the binary input stream or the large text resource using Ec.resource.getLocationStream (String location).In addition to reading resources directly, there are quite a few operations that can use Ec.resource.getLocationReference (String location) The Org.moqui.context.ResourceReference method obtains an instance of the interface similar to the resource façade method, which has some methods for obtaining text and binary stream data from the resource. Interfaces also have methods for directory resources to get subordinate resources, recursively find all subordinate files or directories by name, write text or binary stream data, and move resources to other locations. template rendering and running scriptsA separate method to render a template under a resource path:Ec.resource.renderTemplateInCurrentContext (String location,writer writer). This method does not return anything, just a simple output template to writer. The FTL (freemaker template Language) and gstring (Grovvy String) templates are supported by default. Other templates can be done by implementing the Org.moqui.context.TemplateReader interface and adding resource-facade.template-renderer elements to the moqui XML configuration file. run the script through the resource façade using the object Ec.resource.runScriptCurrentContext (String location,string method) approach. The location of the script and the method to be run in the script as the specified entry will return the corresponding method return value of the script or the object object that evaluates the result. In the resource façade this method also has the mutation usage, it can conveniently accept a map type the Additionalcontext parameter. By default, the Javax.script.ScriptEngineManager.Moqui framework supports grovvy XML actions, JavaScript, and scripts supported by any scripting engine. ways to add a script executor:the 1.javax.script method implements the Javax.script.ScripeEngine interface for any scripting language, and can be javax.script.ScriptEngineManager to discover scripts. The MOAUI framework uses this extension to discover that script-based filenames will compile the script and cache the script in a compiled form to execute a script more quickly and repeatedly in a given location. 2. Implement the Org.moqui.context.ScriptRunner interface and add a RESOURCE-FACADE.SCRIPT-RUNNER element node to the Moquixml configuration file, and the Moqui framework uses the Grovvy XML operation through this interface because he provides Additional convenience, but is not available through the Javax.script interface. since grovvy is the default expression language in the Moaui framework, here are some resource façade methods that can be used for simple, different-purpose expression calculations:

• The Boolean evaluatecondition (string expression, String debuglocation) is used to evaluate a grovvy conditional expression and return the Bolean result.
• The Object evaluatecondition (string expression, String debuglocation) is used to evaluate a field in the context of the return of an expression, and is usually more useful for calculating a person's good grovvy expression and returning the result.
• String Evaluatecondition (string expression, String debuglocation) is used to extend the input string as a gstring (Grovvy string) and return the expanded string

All accept a debuglocation parameter to handle the error message. To calculate the speed, these are cached.data Model definition:

<entity entity-name= "DataSource" package-name= "Moqui.basic" cache= "true" >    <field name= "DataSourceId" Type= "id" is-pk= "true"/>    <field name= "Datasourcetypeenumid" type= "id"/> <field name=    " Description "type=" Text-medium "/>    <relationship type=" one "title=" DatasourceType "Related-entity-name=" Enumeration ">        <key-map field-name=" Datasourcetypeenumid "/>    </relationship>    < seed-data>        <moqui.basic.enumerationtype description= "purchased data" enumtypeid= "DataSourceType" enumId= "Dst_purchased_data"/>        <moqui.basic.enumerationtype description= "DATA Source Type" enumtypeid= " DatasourceType "/>    </seed-data></entity>

　　

just like a Java class, the entity has a package name, the full name of the entity is the package name plus the entity name, ${package-name}.${entity-name}based on this pattern, the entity's full name is: Moqui.basic.DataSourcein this example, a Entity.cache property is set to true, which means that the entity will be cached unless the code specifies to find it separately. the Is-pk property of the first field (DATASOURCEID) is set to true, which means that this field is one of the primary key fields of the entity. The third field (description) is a simple field that holds data, is not part of the primary key, and is not a foreign key for the Kia entity. The Field.tyoe is used to specify the data type of the field, and the default options are defined by the Database-list-dictionary-type element in the Moquidefaultconf.xml file. These elements specify the default type settings for each dictionary type, and you can use the Database.database-type element to redefine the override type settings for each database. The second field (datasourcetypeenumid) is the foreign key of the enumeration entity, represented by the relationship element in the entity definition. The enumeration type (ENUMERATIONTYPE) is defined in the two records under the Seed-data element to make the enumeration (enumeration) option, and one of the enumeration options is set for the Datasourcetypeenumid field. The records under the Seed-data element are loaded using the command line load operation with the seed type. here is a very important pattern that allows the framework to know which enumeration type to use Enumtypeid the enumeration enumeration option to filter a field from a generated form. Note the value of the Relationship.title property matches Enumtypeid. In other words, there is this convention for enumerations anyway: The value of Relationship.title is the ID of the type used to filter the drop-down list. in this example, there is a KEY-MAP element below the relationship element, which is only required for the field name of the entity and the field name of the corresponding associated entity. Since the foreign key field name is Datasourcetypeenumid rather than a simple enumid, we need to tell the framework which field to use to associate with. The framework knows the primary key fields of the associated entity, but unless the name of the field matches the name of the primary key field, the framework does not know which fields correspond to which West segments of the entity. The key-map element may not be applicable. Simple to use as follows<relationship type= "One" Related-entity-name= "enumeration"/>The Seed-data element allows you to define some basic data that is necessary to use the entity, and you can also define an aspect of the data model that is loaded into the database by setting the Type property to seed in the Entity-facade-xml file.

<entity-facade-xml type= "seed" ><tutorial tutorialid= "Testone" description= "Test One description"/>< Tutorial tutorialid= "Testtwo" description= "Test" description "/></entity-facade-xml>

　　

Other Entity properties: Group-name: Entity façade (Entity-facade) is used to put an entity into a group for a database, and all databases are available. This value should match the Moqui-conf.entoty-facade.datasource.group-name element in the Moqio XML configuration file. If no value is specified, the default value of the Moqui-conf.entity-facade.default-group-name element is used. The default values available for configuration include: Transaction (default), Analytical,tenantcommon, and nosql.sequence-bank-size: The size of the sequence storages saved in the training. Each time the serial number in the Sequencevalueitem record is consumed by the seqnum in the sequence, it will increase according to this quantity. Sequence-primary-stagger: The maximum number of interleaving is the sequence ID. An occupation increase sequence of 1 increases by 1, and the current serial number ID can be increased by a random number between 1 and the maximum interval.sequence-secondeondary-padded-length: If the front cushion section can be specified, followed by zero padding to the length specified by this property the default length is 2.Optimistic-lock: When set to true, the entity façade compares the same fields in the In-memory Lastupdatestamp field and the database when it updates the record, and if the timestamp does not match, an error is generated and the default is False. No-update-stamp: Entity façade adds a field for each entity by default for optimistic locking mechanisms and data synchronization. Set to False if you do not want to createcache: You can set the following values, default to Falsetrue: Use cache lookup-code can overwritefalse: Do not cache lookup-code can overwritenever: Do not cache lookup-code is not overwrittenAuthorize-skip: Can set the following values: false by defaulttrue: Pass all permission checks for this entityfalse: Do not pass permission checkCreate: Passing permission check for new OperationView: Passing permission checks for queries and read-only operationsview-create: Skip permission Check for query and new operationadditional field properties:encrypt: When set to true, the field is encrypted in the database. Default is FalseEnable-audit-log: When set to True, logs are recorded for all changes and changes in this field and for the modified person. Log data is recorded in the Entityauditlog entity. The default is False. Enable-localization: When the Entity property is set to Itrue, the Localizsdentityfield entity will be viewed at the same time when the value of this field is obtained. If there is a matching record, the localized record is returned instead of the original. Because the default is false for the presentation, translation is done only if the field property is set to true.   entity Extension-xmlentities can be extended without modifying the original volume definition XML file. This is especially useful when you want to extend a part of a common data model of the mantle, such as a general or even a moqui frame, in different components, and keep your extensions relatively independent. You can use the extend-entity element in an entity definition XML file and use the entity element in a mix to achieve the effect. This element has the same attributes as the entity element to define the extension of the original entity, and simply guarantees that the entity-name and Package-name attributes are consistent with the attributes of the original entity element. entity Extension-dbyou can use Userfield entities to extend entities through database records in a way that is somewhat different from extending entities by extend-entity XML elements, because this is a virtual extension And the data is stored in a separate Userfieldvalue entity data structure. The main reason for this difference is that the user field that is typically added is for a group of users or for a single user, and the associated external user is inaccessible except for this group of users. You can use the All-users user group to make a user field work for all users. Although running in the background, the Entityvalue object handles these fields in the same way that the entity treats any other field .examples in eample:

<moqui.entity.userfield entityname= "Moqui.example.Example" fieldname= "Testuserfield" usergroupid= "All_users"                            fieldtype= "Text-long" enableauditlog= "Y" enablelocalization= "n" encrypt= "n"/>

　　

Moqui Learning Data and resources