Ok. I guess I was "conditioned" by the UI in the catalog manager to
think incorrectly that the idea was to have multi contents, each with
a locale, for the same product.
This does sound like a good way to go -- to group related content
together if they are of different locales.
One other thing that confused me that one has to create the
DataResource first, then create a Content which references that
dataResourceId. I had originally thought that the idea was to have
the Content serve as a sort of a "master" with many different data
resources pointing to it. Is that no longer the case?
Si
On Aug 21, 2006, at 10:06 PM, David E Jones wrote:
From a content reuse perspective it allows you to package up all of
the related content (ie for each locale) and be able to refer to it
by a single contentId. With this all you need to know is the "main"
contentId and the locale you would prefer to have it rendered in,
and you're good to go. That is the real goal of the design.
What you can do with this is put together content that can be used
for various things. The same contentId can be referred to in a
Content structure for inclusion in a templated/styled document, or
with a single ProductContent record (instead of one for each
locale) it can all be associated with a Product, or with a
ProductCategoryContent record with a category, and so on. There is
all sorts of flexibility when you only have one contentId to deal
with rather than an arbitrary contentId for each alternate content
for other locales, which would be a mess.
It all comes down to the basic principle that you have to have a
machine usable structure to know about related Content. Once you
have that, why not take advantage of it for other purposes like this?
Now that I right this up it seems a bit too simple and maybe isn't
what you were asking about. Is there some concern that you had
about this structure or how these things are done?
-David
On Aug 21, 2006, at 7:35 PM, Si Chen wrote:
By the way, David - how does having multiple Contents associated
with primary Content as ALTERNATE_LOCALE give more flexibility
than just associating multiple Content with the Product? Sorry
but I don't quite see it.
Si
Begin forwarded message:
From: "David E. Jones (JIRA)" <[EMAIL PROTECTED]>
Date: August 21, 2006 9:58:15 AM PDT
To: [email protected]
Subject: [jira] Commented: (OFBIZ-161) Fix contentwrapper locale
rendering bug
Reply-To: [email protected]
[ http://issues.apache.org/jira/browse/OFBIZ-161?
page=comments#action_12429458 ]
David E. Jones commented on OFBIZ-161:
--------------------------------------
Please don't commit this.
The pattern this uses points to multiple ProductContent records
for different locales and is not how the Content and related
entities are meant to be used.
There should be a single Content record that is in turn related
to other content records through ContentAssoc using
contentAssocTypeId="ALTERNATE_LOCALE".
Pointing to a single Content record that is in turn related to
alternate locale content pushes the logic and structure back into
the content area which makes it more re-usable, and easier to
multi-purpose the content.
Fix contentwrapper locale rendering bug
---------------------------------------
Key: OFBIZ-161
URL: http://issues.apache.org/jira/browse/OFBIZ-161
Project: OFBiz (The Open for Business Project)
Issue Type: Bug
Components: product
Reporter: Si Chen
Attachments: content-wrapper-locale.patch
Wanted to check with everybody before committing this to make
sure I'm not going down the wrong way.
It seems to me that you should be able to create content for
products and categories in different languages in the Catalog
Manager by clicking on the [Content] tab of Product or Category,
then click on [Prepare Create] for say, Description or Long
Description. Then you should be able to enter a locale, and
that content should be the one for that language locale.
However, the Product and Category ContentWrappers were not
rendering them.
After a little digging, it seemed to me the problem was that
they were both looking for the ProductContent and
ProductCategoryContent entities, then getting the first and most
recent record of each as the Content to render. There was no
filtering of locale of the Content entity--hence no way to
control which locale was being rendered.
I made this little patch to change the lookup to
ProductContentAndInfo and the comparable Categoryentity. It
fixed it for me, so now I can enter English as en_US and French
as fr_FR, and the content for those languages would render
separately.
However, one problem is that this content lookup is very strict
- if you create your content as en, it will not find it as
en_US, or vice versa.
Is this the right way to use the content manager?
Is there a way to make it so that en_ will work for en_US--other
than some fancier searching technique?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://issues.apache.org/jira/secure/
Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/
software/jira
