Andriy Vovchyna wrote:

Hi!

We are planning to introduce "Documents" that will have a set of additional attributes besides Content as regular xwiki page has.

For example our "Document" will contain

a) Name

b) Content

c) State

d) Rating

Questions are about proper attributes distribution between xwiki page and object (instance of additional xwiki class will be designed)

Currently we see two reasonable ways. In both cases Name will be name of page where our "Document" "stored".

1) Content in page

* Content is stored in a page content * State and Rating are attributes of some class (e.g. OurDocClass), stored as an object on this page.

If you need a special method of display, you can have a single code document and use the {{include}} macro to include that code. In that case the {{include}} will pollute your content. There also may be issues with the included script reading the content correctly.

2) Content in class

* Content, State and Rating are attributes of some class * Page is just to display (may edit) properties (including Content) of the object "attached" to particular page

This is most commonly used on xwiki.org. Each entity is represented by a page which contains a single object of the class and the only thing in the document content is an {{include}} macro which points to the class sheet which handles display and editing of the object. See an example: http://code.xwiki.org/xwiki/bin/view/Applications/InvitationApplication?view... Only content is a link to the class sheet. http://code.xwiki.org/xwiki/bin/view/XWiki/ApplicationClassSheet?viewer=code... The class sheet takes the object and makes a pretty display. Note how it behaves differently if the action is 'inline' rather than 'view', this allows it to be used for viewing and editing. http://code.xwiki.org/xwiki/bin/view/XWiki/ApplicationClassTemplate?viewer=c... This document is used as a template, it's copied to make all new documents created by the CreateApplication app. What you can't see is that the template also contains an object of the ApplicationClass. http://code.xwiki.org/xwiki/bin/view/Applications/CreateApplication?viewer=c... This document is used to create new documents of this type (application). What's important is that the name of the template is included so the template can be copied to the new document.

I prefer to use first way, but there we have a dispute in our implementation team.

Questions:

a) What way is preferable?

I myself would prefer the second.

b) What benefits and disadvantages of using #1 ?

Answered above.

c) Are there possible some performance issues if we store bulky content text in object property instead of page content?

Probably not, if the system is so large that it becomes an issue you might consider looking at using custom Hibernate mappings for the objects.

I suppose in case #2 we can meet inconvenience with powerful using of other xwiki functionality which we are planning to use, such as Lucene Searching, Document Locking, Versioning, Including of page etc.

Each document only contains one set of objects, not one per translation language. I don't know much about the Lucene engine, maybe someone else can speak more on that. Caleb

It will be nice to get recommendations or references to some staff on xwiki.org.

Thank you,

Andriy

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

On Sat, Sep 18, 2010 at 12:38 PM, [Ricardo Rodriguez] eBioTIC. <[email protected]> wrote: Hi, You can use translations (See http://platform.xwiki.org/xwiki/bin/view/DevGuide/InternationalizingApplicat...). For class properties, the translation format is like this: ClassSpaceBane.ClassDocName_propertyName=A_Translation_Text So you need a single document with multiple translations. Raluca.

Hi!

Caleb James DeLisle wrote:

...

Each document only contains one set of objects, not one per translation language.

Thus, please, how do you propose to manage/store information that depends on location? For instance, a given property of a given class has different values/translations. For instance, commonName in the class Species has a value in Spanish, another one in English and it is expected to have a different one for any new translation. It seems to me that this forces to store that value in the document body or to create a new property for each new translation.

Any idea will be welcome!!! Thanks!

Ricardo

-- Ricardo Rodríguez CTO eBioTIC. Life Sciences, Data Modeling and Information Management Systems

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

Thanks, Raluca, Raluca Stavro wrote:

On Mon, Sep 20, 2010 at 9:29 AM, Raluca Stavro <[email protected]> wrote:

...

On Sat, Sep 18, 2010 at 12:38 PM, [Ricardo Rodriguez] eBioTIC. <[email protected]> wrote: Hi,

You can use translations (See http://platform.xwiki.org/xwiki/bin/view/DevGuide/InternationalizingApplicat...). For class properties, the translation format is like this:

ClassSpaceBane.ClassDocName_propertyName=A_Translation_Text

ClassSpaceName.ClassDocName_propertyName=A_Translation_Text

I'm in fact using this method in a rather simple application we have created, but whereas it is rather simple to edit and fill-in properties in a given instantiate class, it is not so "straight" to use the method we talk about here to the same. For instance, consider this (awful, but it could be useful to illustrate the discussion) model... http://ftp.ebiotic.net/onPdr/pescaderiasDataModel.png I've implemented it by using Documents to instantiate User and Species classes. Species classes has two properties that hold translations of its name. If I manage to get a new translation, I do need to add a new property to this class. Or to instruct translators to edit the translations document and fill in the property the name of the variable in the format you have told before. I do prefer not to have people to tweak with this kind of "raw" XWiki documents. Could it be possible to create a new class for each name to be translated and instatiate it such many times as different languages a given name is translated to? This class will have two properties: Language Code and Translation. WDYT? I think all I have to do is to understand how http://l10n.xwiki.org works! But I think this is a bit far from my capabilities rigth now! As stated in some other message, any entry-level help will be welcome! Thanks! -- Ricardo Rodríguez CTO eBioTIC. Life Sciences, Data Modeling and Information Management Systems

Thanks, Raluca. Raluca Stavro wrote:

See this document in order to learn the basics of the translations module: http://platform.xwiki.org/xwiki/bin/view/Features/I18N .

A trick to solve your problem would be to have a single 'name' property for the 'Species' class. Let's say that you attached an object of type 'YourSpace.Species' class to a document named 'YourSpace.DocName'. You set the value of the 'name' property to 'sp_name_key' (use a key in order to be able to use translations based on it). Edit the document in wiki mode and write: {{velocity}} #set($thisDocSpeciesNameKey = $doc.getObject('YourSpace.Species').getProperty('name').value) ## $thisDocSpeciesNameKey value is 'sp_name_key' $msg.get("$!thisDocSpeciesNameKey") {{/velocity}} ## save the document

In the translations document, for the 'en' version you write the key & value like this: sp_name_key=my EN sp name ## save the document

For the 'fr' version, you write this: sp_name_key=my FR sp name ## save the document

Now, if you go to .../view/YourSpace/DocName (your document in 'view' mode), by changing the language you will see that the displayed name is different for each language.

I think I see how this works. I'll implement sample here. I'm already using this method for panels, but I've never used it for class properties. But, in any case, I'll also try to write a model for using a kind of "translation class". Is the application available at http://l10n.xwiki.org working the way you describe? Thanks! Ricardo -- Ricardo Rodríguez CTO eBioTIC. Life Sciences, Data Modeling and Information Management Systems