Design & architecture - dynamic customized use cases

[marius]

Hi,

Please consider that I have integrated the integration, personalization,  search and security modules, which helps me in using some fs tags and  functionalities (in order to query some data, create some new data,  modify/delete a.s.o.).

The functionality offered through these modules is not enough in some  special cases... and I will need to integrate more business related  code/actions. So, what am I doing is:
- I'm using JSP templates (FS- Template store, Page templates ->  properties : target: JSP)
- I integrated a MVC framework (like Stripes, Struts, ...) and from  inside of the generated JSP templates (integrated with FS) I configured  so that the submitted action points to my new dynamic code (Stripes Java  action classes... or Struts actions... or JSF ...whatever)

everything fine so far...

now, inside of the new Java action classes I would like to integrate  some DAO functionality.

Questions:
1. Shall I use the FirstSpirit API to modify/create/delete some entities  (which are also used by my FS templates to generate static code)?
Does FS API provide such of classes that allows me to execute DAO  operations? ... or I should configure an ORM (like hibernate, JPA) on  top of the FS tables, in order to work with CRUD operations?

2. Do I have access to some FS transaction mechanism so I can  start/commit/rollback new customized transactions?

3. Is there an horizontal service available (AOP) for the transaction  support?

4. From the design & architecture point of view, please let me know  which is the most recommended way by "FirstSpirit standards" to manage  entities (CRUD operations on DB records) from these customized java  action classes.


Would you recommend for these customized business use cases to integrate  something like: Spring & Hibernate/JPA   ... or anything else? ... I  just want to avoid introducing inconsistent data into the FS system...  and I would like to stay as much as possible with FS standards for all  points of view (what the modules cover and the exceptional cases).

Thanks,
Marius

[pjodeleit]

With which type of entities do you want to work with? de.espirit.firstspirit.access.store.pagestore.Page, de.espirit.firstspirit.access.store.pagestore.Section, ...? Or de.espirit.or.schema.Entity?

I think the latter, since you are talking about 'tables'. Please keep in mind that FS has a temporal aspect in its database tables and that tools like Hibernate and JPA do not support this aspect.

[Andreas-Knoor]

Marius Cimpean schrieb:

4. From the design & architecture point of view, please let me know  which is the most recommended way by "FirstSpirit standards" to manage  entities (CRUD operations on DB records) from these customized java  action classes.

Could you describe what functional requirements should be realized with this CRUD operations?

[bohm · Accepted solution]

Hi Marius,

I talked to our development team and basically our answer is:

We offer a way to access database content via our OR API. This API includes commit and rollback-functionality, so basic transaction mechanisms are available.

By using this API it is ensured that versioning and revision information is stored correctiy in the database.

At present we discourage the use of frameworks such as spring or hibernate. An example of a C-Operation using our API is this:

import de.espirit.or.Session;
import de.espirit.or.web.SessionManager;
import de.espirit.or.schema.Entity;
String schemaName = "schemaname";
Session orSession = SessionManager.getInstance(getServletContext()).getSession(schemaName);


try {
    Entity myEntity = orSession.createEntity("peopledata");

    myEntity.setValue("lastname", lastname);
    myEntity.setValue("firstname", firstname);
    // ...

    orSession.commit();
} catch (ORException ore) {
    // error handling procedures
    session.rollback();
}

[marius]

The CRUD operations should support: Create, Read, Update and Delete database operations.

[pjodeleit]

Here the other operations.

Read

  Entity myEntity = orSession.find(4711, "peopledata");
  List<Entity> list = orSession.executeQuery(orSession.createSelect("peopledata"));

Update

  myEntity.setValue("lastname", "Meyer");
  orSession.commit();

Delete

  orSession.delete(myEntity);
  orSession.commit();

--Peter

[marius]

Thanks for the answers.

In the end I will have to use the FS API for the DB operations, just because there are operations which have to be taken care of, like versioning and revision information.

I would also like to do a suggestion for the FS development team (that might be considered for later versions). This suggestion started from the following aspect:

- just imagine that the application I need to develop with FS has around 100 tables... and about 50 tables needs to support dynamic operations which could not be covered by the FS Integration module. From this point of view I will have to implement all DAO related code operations for the 50 tables...

which is :

- time consuming,

- usually, when you have to deal with code like:

      myEntity.setValue("lastname", lastname);

there is enough place for bugs (misspelling attribute names);

- whenever an attribute changes in the DB schema, or new show up or they are removed the code has to be changed again;

- tests required

- the FS Integration module is designed for Java scriplets usage...which I would strongly like to avoid (no scriplets in JSP).

Because of these aspects and based on the fact that you already developed a nice DB design tool which produces an XSD file I would suggest the following:

- make FS available to plugin with ORM frameworks

- by using the XSD file there could be designed a cartridge that could be later used with an external tool (like AndroMDA) for generating basic DAO functionality, like value objects (PeopleData Java class with getters/setters), DAO classes, a.s.o.  that could be extended by customized classes in order to provide extra functionality.

Marius

[marius]

Hi,

By running the following code (as suggested) :

Session orSession = SessionManager.getInstance(getSession().getServletContext()).getSession("agro");

I get the following exceptions:

java.lang.IllegalArgumentException: SessionManager.createSession: no handler registered for schema 'agro'
    at de.espirit.or.impl.web.SessionManagerImpl.createSession(SessionManagerImpl.java:114)
    at de.espirit.or.impl.web.SessionManagerImpl.getSession(SessionManagerImpl.java:62)

Could you be so kind and provide me with a basic / running sample. It might be that I'm missing some configuration?

Is there any documentation related to this? complete API docu? PDF ? ... anything that I could get ?

Thanks,

Marius

[pjodeleit]

http://www.e-spirit.com/odfs42/media/dokumentation/dokumentation_module/dokumentation_entwickler_1/I...

I think chapter 2.3.1 it's what you are looking for.

Also available in german: http://www.e-spirit.com/odfs42/media/dokumentation/dokumentation_module/dokumentation_entwickler_1/I...

[marius]

This is not related to the configuration of database schema. I already did  this and this is working if I use the Integration module with the tag libs.

What I am trying to do right now is related to the API, I need to access the  database through the FirstSpirit API (session manager). My code is located into  the a web Java action (stripes,struts ... a MVC framework).

From the exception I got, it looks to me that I need to register a handler.  Any idea?