Users - Product newbie questions

[Walter Vaughan]

We make parts for automobiles. Our products can have up to 8 different standard
and long descriptions. Most have three or four different descriptions depending
on the make of the car. We don't want (and our customers don't) to have to give
model useage decriptions that don't apply.

Since there is only one "long description" field, is there a document somewhere
  that is a best practices guide that would guide us through setting up a single
part numbers that would have multiple long descriptions dependent upon what
cataegory the product is associated with.

Thanks

--
Walter
 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[BJ Freeman]

there maybe other suggestions but look at the BOM demo.
if I remember right it allows you to come up with multiple parts numbers
based on the root part number.
something similar would work, I think for descriptions.

Walter Vaughan sent the following on 6/18/06 2:57 PM:

> We make parts for automobiles. Our products can have up to 8 different standard
> and long descriptions. Most have three or four different descriptions depending
> on the make of the car. We don't want (and our customers don't) to have to give
> model useage decriptions that don't apply.
>
> Since there is only one "long description" field, is there a document somewhere
>   that is a best practices guide that would guide us through setting up a single
> part numbers that would have multiple long descriptions dependent upon what
> cataegory the product is associated with.
>
> Thanks
>
> --
> Walter
>  
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Walter Vaughan]

BJ Freeman wrote:

> there maybe other suggestions but look at the BOM demo.

Maybe the light didn't go off for me. You are talking about the
sequoiaerp-0.8-manufacturing-1-create-bill-of-materials-avi ?

> Walter Vaughan sent the following on 6/18/06 2:57 PM:
>>We make parts for automobiles. Our products can have up to 8 different standard
>>and long descriptions.


Currently we have category drill downs like the following:
Rubber Parts -> Cadillac -> 1950's -> 1958:

Here's an example of a part that has many different descriptions, but would be
confusing for someone to read...
-
Buick 1954-58 Weatherstrip, front door auxiliary, on door at beltline, right
and left. Replaces #4698923-4, #4654139-40, uses snap-in fasteners, 4 each included.
     * 1954-56: Series 50, 70 (must shorten slightly)
       1957-58: All
-
Cadillac 1954-58 Weatherstrip, front door auxiliary, on door at beltline, right
and left. Replaces #4698923-4, #4654139-40, uses snap-in fasteners (4 each
included in set). All except Eldorado Brougham.
-
Chevrolet 1958 Weatherstrip, front door auxiliary on door at beltline, right and
left. Replaces #4698923-4, uses snap-in fasteners, 4 each included in set. All
models.
-
Oldsmobile 1957-58 Weatherstrip, front door auxiliary on door at beltline, right
and left. Replaces #4698923-4, uses snap in fasteners. 4 fasteners included in
set. All models.
-
Pontiac 1958 Weatherstrip, front door auxiliary on door at beltline, right and
left. Replaces #4698923-4, uses snap in fasteners. 4 fasteners included in set.
Styles 2741, 49, 93, 94; 2849.
-

We've already built the drill down categories such that I can get to year and
make. But for example I only want to show the "Cadillac" description to people
who have drilled down from the Cadillac category. I have the a category_id
1958CADILLAC and I have the Cadillac only description in a separate record with
a matching category_id.

Am I chasing my tail here? The BOM video would lead me to extend the part number
that is all of the above (70-0551-73) into numbers like 70-0551-73-BU,
70-0551-73-CA, etc.. My "newbieness" then makes me wonder how do I deal with
inventory, onhand, invoicing and sales accounting.

Is this something to submit to Jira?

Help.

--
Walter
 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[BJ Freeman]

I am not familiar with sequoiaerp
here is place for it
http://sourceforge.net/support/getsupport.php?group_id=145855

Walter Vaughan sent the following on 6/19/06 5:53 AM:

> BJ Freeman wrote:
>
>
>>there maybe other suggestions but look at the BOM demo.
>
>
> Maybe the light didn't go off for me. You are talking about the
> sequoiaerp-0.8-manufacturing-1-create-bill-of-materials-avi ?
>
>
>>Walter Vaughan sent the following on 6/18/06 2:57 PM:
>>
>>>We make parts for automobiles. Our products can have up to 8 different standard
>>>and long descriptions.
>
>
>
> Currently we have category drill downs like the following:
> Rubber Parts -> Cadillac -> 1950's -> 1958:
>
> Here's an example of a part that has many different descriptions, but would be
> confusing for someone to read...
> -
> Buick 1954-58 Weatherstrip, front door auxiliary, on door at beltline, right
> and left. Replaces #4698923-4, #4654139-40, uses snap-in fasteners, 4 each included.
>      * 1954-56: Series 50, 70 (must shorten slightly)
>        1957-58: All
> -
> Cadillac 1954-58 Weatherstrip, front door auxiliary, on door at beltline, right
> and left. Replaces #4698923-4, #4654139-40, uses snap-in fasteners (4 each
> included in set). All except Eldorado Brougham.
> -
> Chevrolet 1958 Weatherstrip, front door auxiliary on door at beltline, right and
> left. Replaces #4698923-4, uses snap-in fasteners, 4 each included in set. All
> models.
> -
> Oldsmobile 1957-58 Weatherstrip, front door auxiliary on door at beltline, right
> and left. Replaces #4698923-4, uses snap in fasteners. 4 fasteners included in
> set. All models.
> -
> Pontiac 1958 Weatherstrip, front door auxiliary on door at beltline, right and
> left. Replaces #4698923-4, uses snap in fasteners. 4 fasteners included in set.
> Styles 2741, 49, 93, 94; 2849.
> -
>
> We've already built the drill down categories such that I can get to year and
> make. But for example I only want to show the "Cadillac" description to people
> who have drilled down from the Cadillac category. I have the a category_id
> 1958CADILLAC and I have the Cadillac only description in a separate record with
> a matching category_id.
>
> Am I chasing my tail here? The BOM video would lead me to extend the part number
> that is all of the above (70-0551-73) into numbers like 70-0551-73-BU,
> 70-0551-73-CA, etc.. My "newbieness" then makes me wonder how do I deal with
> inventory, onhand, invoicing and sales accounting.
>
> Is this something to submit to Jira?
>
> Help.
>
> --
> Walter
>  
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Si Chen-2]

Wow.  BOM is not what you should be looking at.  Don't go down that  
track.

If you are setting up your cars as products, can you use one of the  
fields on ProductAssoc to store the description related to that car  
product?  Otherwise, if you're setting up your cars as categories,  
you might want to add a field to ProductCategoryMember which is a  
description of that product when it is part of that category.  The  
standard OFBiz entities are fairly generic, and Products and  
Categories are self-contained, but you can add these additional  
fields if you need them.

Si


On Jun 18, 2006, at 2:57 PM, Walter Vaughan wrote:

> We make parts for automobiles. Our products can have up to 8  
> different standard
> and long descriptions. Most have three or four different  
> descriptions depending
> on the make of the car. We don't want (and our customers don't) to  
> have to give
> model useage decriptions that don't apply.
>
> Since there is only one "long description" field, is there a  
> document somewhere
>   that is a best practices guide that would guide us through  
> setting up a single
> part numbers that would have multiple long descriptions dependent  
> upon what
> cataegory the product is associated with.
>
> Thanks
>
> --
> Walter
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Walter Vaughan]

Si Chen wrote:

> Wow.  BOM is not what you should be looking at.  Don't go down that  
> track.

That's what we thought.

> If you are setting up your cars as products, can you use one of the  
> fields on ProductAssoc to store the description related to that car  
> product?  Otherwise, if you're setting up your cars as categories,  
> you might want to add a field to ProductCategoryMember which is a  
> description of that product when it is part of that category.  The  
> standard OFBiz entities are fairly generic, and Products and  
> Categories are self-contained, but you can add these additional  
> fields if you need them.

Okay. But here's something that is Not Very Clear Anywhere. If we add extra
fields to the ProductCategoryMember file like "description" and "long
description" how will that play with using svn and ant? What we don't want to do
for a long time (or ever) is cause a fork in how we need to do things vs. the
general ofBiz distributions. We have a specific need for Catalog mailing
management that we plan on re-writing in the ofBiz framework that we plan on
contributing back to the project, so we really don't want to get off the path at
all if we can help it.

We had a small discussion about this today, and for a while it seemed that the
stance that every shopping cart system takes (a fixed description) was the
proper way, and we are wrong in how we present our information. However another
product example came up. What about "baking soda". It could be sold as something
to remove odors or something to make tasty cookies. You wouldn't want to talk
about how "baking soda" removes  smelly odors from rancid bathroom fixtures when
someone is looking at it from a chocolate cookie ingredient perspective.

Thinking out loud... we'll have to re-program ofBiz (or pay someone to) to check
the ProductCategoryMember file for non-null description fields and use that text
instead of what is in the Product file for catalog display purposes. Then get a
core committer to agree to add in the changes so that this newly added feature
would be a function of the core product.

Is my thinking correct on this?

Thanks

--
Walter
 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Walter Vaughan]

Okay we are very much stuck now at the "what's next" stage. We have no idea on
how to handle the product description issues, and are at a loss to determine
what to do next if we cannot even display our products with the correct
description depending upon the category the part is in.

What's maddening to us is that the "entity-engine" has a table called
"ProductCategoryAndMembers" that has a all the fields we are probably looking to
use, but the long description goes at the category top, rather than the
product_id, which makes no sense, why have product_id in the record if it's does
not apply to the record displayed.

Argh.

Thanks for allowing me to vent.

--
Walter



Walter Vaughan wrote:

> Si Chen wrote:
>
>
>>Wow.  BOM is not what you should be looking at.  Don't go down that  
>>track.
>
>
> That's what we thought.
>
>
>>If you are setting up your cars as products, can you use one of the  
>>fields on ProductAssoc to store the description related to that car  
>>product?  Otherwise, if you're setting up your cars as categories,  
>>you might want to add a field to ProductCategoryMember which is a  
>>description of that product when it is part of that category.  The  
>>standard OFBiz entities are fairly generic, and Products and  
>>Categories are self-contained, but you can add these additional  
>>fields if you need them.
>
>
> Okay. But here's something that is Not Very Clear Anywhere. If we add extra
> fields to the ProductCategoryMember file like "description" and "long
> description" how will that play with using svn and ant? What we don't want to do
> for a long time (or ever) is cause a fork in how we need to do things vs. the
> general ofBiz distributions. We have a specific need for Catalog mailing
> management that we plan on re-writing in the ofBiz framework that we plan on
> contributing back to the project, so we really don't want to get off the path at
> all if we can help it.
>
> We had a small discussion about this today, and for a while it seemed that the
> stance that every shopping cart system takes (a fixed description) was the
> proper way, and we are wrong in how we present our information. However another
> product example came up. What about "baking soda". It could be sold as something
> to remove odors or something to make tasty cookies. You wouldn't want to talk
> about how "baking soda" removes  smelly odors from rancid bathroom fixtures when
> someone is looking at it from a chocolate cookie ingredient perspective.
>
> Thinking out loud... we'll have to re-program ofBiz (or pay someone to) to check
> the ProductCategoryMember file for non-null description fields and use that text
> instead of what is in the Product file for catalog display purposes. Then get a
> core committer to agree to add in the changes so that this newly added feature
> would be a function of the core product.
>
> Is my thinking correct on this?
>
> Thanks
>
> --
> Walter
>  
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Si Chen-2]

On Jun 20, 2006, at 1:12 PM, Walter Vaughan wrote:

> Okay we are very much stuck now at the "what's next" stage. We have  
> no idea on
> how to handle the product description issues, and are at a loss to  
> determine
> what to do next if we cannot even display our products with the  
> correct
> description depending upon the category the part is in.
>
Have you thought about using ProductCategoryMember.instructions to  
store your information.

> What's maddening to us is that the "entity-engine" has a table called
> "ProductCategoryAndMembers" that has a all the fields we are  
> probably looking to
> use, but the long description goes at the category top, rather than  
> the
> product_id, which makes no sense, why have product_id in the record  
> if it's does
> not apply to the record displayed.
>
This is probably for lookup purposes.  It's a view-entity that you're  
referring to.

> Argh.
>
> Thanks for allowing me to vent.
>
> --
> Walter
>
>
>
> Walter Vaughan wrote:
>
>> Si Chen wrote:
>>
>>
>>> Wow.  BOM is not what you should be looking at.  Don't go down that
>>> track.
>>
>>
>> That's what we thought.
>>
>>
>>> If you are setting up your cars as products, can you use one of the
>>> fields on ProductAssoc to store the description related to that car
>>> product?  Otherwise, if you're setting up your cars as categories,
>>> you might want to add a field to ProductCategoryMember which is a
>>> description of that product when it is part of that category.  The
>>> standard OFBiz entities are fairly generic, and Products and
>>> Categories are self-contained, but you can add these additional
>>> fields if you need them.
>>
>>
>> Okay. But here's something that is Not Very Clear Anywhere. If we  
>> add extra
>> fields to the ProductCategoryMember file like "description" and "long
>> description" how will that play with using svn and ant? What we  
>> don't want to do
>> for a long time (or ever) is cause a fork in how we need to do  
>> things vs. the
>> general ofBiz distributions. We have a specific need for Catalog  
>> mailing
>> management that we plan on re-writing in the ofBiz framework that  
>> we plan on
>> contributing back to the project, so we really don't want to get  
>> off the path at
>> all if we can help it.
>>
>> We had a small discussion about this today, and for a while it  
>> seemed that the
>> stance that every shopping cart system takes (a fixed description)  
>> was the
>> proper way, and we are wrong in how we present our information.  
>> However another
>> product example came up. What about "baking soda". It could be  
>> sold as something
>> to remove odors or something to make tasty cookies. You wouldn't  
>> want to talk
>> about how "baking soda" removes  smelly odors from rancid bathroom  
>> fixtures when
>> someone is looking at it from a chocolate cookie ingredient  
>> perspective.
>>
>> Thinking out loud... we'll have to re-program ofBiz (or pay  
>> someone to) to check
>> the ProductCategoryMember file for non-null description fields and  
>> use that text
>> instead of what is in the Product file for catalog display  
>> purposes. Then get a
>> core committer to agree to add in the changes so that this newly  
>> added feature
>> would be a function of the core product.
>>
>> Is my thinking correct on this?
>>
>> Thanks
>>
>> --
>> Walter
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/users
>>
>>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Alexandre Gomes-5]

Hi Walter,

ProductCategoryAndMembers is a view created on the fly from the tables
ProductCategory and ProductCategoryMember.

You should add a description field to the ProductCategoryMember table
and then change the productsummary.ftl and productsummary.bsh files so
the description field in the category detail page maps the description
of that product for that category.

Alexandre Gomes

On 6/20/06, Walter Vaughan <[hidden email]> wrote:

> Okay we are very much stuck now at the "what's next" stage. We have no idea on
> how to handle the product description issues, and are at a loss to determine
> what to do next if we cannot even display our products with the correct
> description depending upon the category the part is in.
>
> What's maddening to us is that the "entity-engine" has a table called
> "ProductCategoryAndMembers" that has a all the fields we are probably looking to
> use, but the long description goes at the category top, rather than the
> product_id, which makes no sense, why have product_id in the record if it's does
> not apply to the record displayed.
>
> Argh.
>
> Thanks for allowing me to vent.
>
> --
> Walter
>
>
>
> Walter Vaughan wrote:
>
> > Si Chen wrote:
> >
> >
> >>Wow.  BOM is not what you should be looking at.  Don't go down that
> >>track.
> >
> >
> > That's what we thought.
> >
> >
> >>If you are setting up your cars as products, can you use one of the
> >>fields on ProductAssoc to store the description related to that car
> >>product?  Otherwise, if you're setting up your cars as categories,
> >>you might want to add a field to ProductCategoryMember which is a
> >>description of that product when it is part of that category.  The
> >>standard OFBiz entities are fairly generic, and Products and
> >>Categories are self-contained, but you can add these additional
> >>fields if you need them.
> >
> >
> > Okay. But here's something that is Not Very Clear Anywhere. If we add extra
> > fields to the ProductCategoryMember file like "description" and "long
> > description" how will that play with using svn and ant? What we don't want to do
> > for a long time (or ever) is cause a fork in how we need to do things vs. the
> > general ofBiz distributions. We have a specific need for Catalog mailing
> > management that we plan on re-writing in the ofBiz framework that we plan on
> > contributing back to the project, so we really don't want to get off the path at
> > all if we can help it.
> >
> > We had a small discussion about this today, and for a while it seemed that the
> > stance that every shopping cart system takes (a fixed description) was the
> > proper way, and we are wrong in how we present our information. However another
> > product example came up. What about "baking soda". It could be sold as something
> > to remove odors or something to make tasty cookies. You wouldn't want to talk
> > about how "baking soda" removes  smelly odors from rancid bathroom fixtures when
> > someone is looking at it from a chocolate cookie ingredient perspective.
> >
> > Thinking out loud... we'll have to re-program ofBiz (or pay someone to) to check
> > the ProductCategoryMember file for non-null description fields and use that text
> > instead of what is in the Product file for catalog display purposes. Then get a
> > core committer to agree to add in the changes so that this newly added feature
> > would be a function of the core product.
> >
> > Is my thinking correct on this?
> >
> > Thanks
> >
> > --
> > Walter
> >
> > _______________________________________________
> > Users mailing list
> > [hidden email]
> > http://lists.ofbiz.org/mailman/listinfo/users
> >
> >
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Alexandre Gomes-5]

You should also change AddProductCategoryMember and
AddProductCategoryMember forms so you can use the Catalog Manager to
change the field.

Alex

On 6/21/06, Alexandre Gomes <[hidden email]> wrote:

> Hi Walter,
>
> ProductCategoryAndMembers is a view created on the fly from the tables
> ProductCategory and ProductCategoryMember.
>
> You should add a description field to the ProductCategoryMember table
> and then change the productsummary.ftl and productsummary.bsh files so
> the description field in the category detail page maps the description
> of that product for that category.
>
> Alexandre Gomes
>
> On 6/20/06, Walter Vaughan <[hidden email]> wrote:
> > Okay we are very much stuck now at the "what's next" stage. We have no idea on
> > how to handle the product description issues, and are at a loss to determine
> > what to do next if we cannot even display our products with the correct
> > description depending upon the category the part is in.
> >
> > What's maddening to us is that the "entity-engine" has a table called
> > "ProductCategoryAndMembers" that has a all the fields we are probably looking to
> > use, but the long description goes at the category top, rather than the
> > product_id, which makes no sense, why have product_id in the record if it's does
> > not apply to the record displayed.
> >
> > Argh.
> >
> > Thanks for allowing me to vent.
> >
> > --
> > Walter
> >
> >
> >
> > Walter Vaughan wrote:
> >
> > > Si Chen wrote:
> > >
> > >
> > >>Wow.  BOM is not what you should be looking at.  Don't go down that
> > >>track.
> > >
> > >
> > > That's what we thought.
> > >
> > >
> > >>If you are setting up your cars as products, can you use one of the
> > >>fields on ProductAssoc to store the description related to that car
> > >>product?  Otherwise, if you're setting up your cars as categories,
> > >>you might want to add a field to ProductCategoryMember which is a
> > >>description of that product when it is part of that category.  The
> > >>standard OFBiz entities are fairly generic, and Products and
> > >>Categories are self-contained, but you can add these additional
> > >>fields if you need them.
> > >
> > >
> > > Okay. But here's something that is Not Very Clear Anywhere. If we add extra
> > > fields to the ProductCategoryMember file like "description" and "long
> > > description" how will that play with using svn and ant? What we don't want to do
> > > for a long time (or ever) is cause a fork in how we need to do things vs. the
> > > general ofBiz distributions. We have a specific need for Catalog mailing
> > > management that we plan on re-writing in the ofBiz framework that we plan on
> > > contributing back to the project, so we really don't want to get off the path at
> > > all if we can help it.
> > >
> > > We had a small discussion about this today, and for a while it seemed that the
> > > stance that every shopping cart system takes (a fixed description) was the
> > > proper way, and we are wrong in how we present our information. However another
> > > product example came up. What about "baking soda". It could be sold as something
> > > to remove odors or something to make tasty cookies. You wouldn't want to talk
> > > about how "baking soda" removes  smelly odors from rancid bathroom fixtures when
> > > someone is looking at it from a chocolate cookie ingredient perspective.
> > >
> > > Thinking out loud... we'll have to re-program ofBiz (or pay someone to) to check
> > > the ProductCategoryMember file for non-null description fields and use that text
> > > instead of what is in the Product file for catalog display purposes. Then get a
> > > core committer to agree to add in the changes so that this newly added feature
> > > would be a function of the core product.
> > >
> > > Is my thinking correct on this?
> > >
> > > Thanks
> > >
> > > --
> > > Walter
> > >
> > > _______________________________________________
> > > Users mailing list
> > > [hidden email]
> > > http://lists.ofbiz.org/mailman/listinfo/users
> > >
> > >
> >
> >
> > _______________________________________________
> > Users mailing list
> > [hidden email]
> > http://lists.ofbiz.org/mailman/listinfo/users
> >
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Walter Vaughan]

Alexandre Gomes wrote:

> Hi Walter,
>
> ProductCategoryAndMembers is a view created on the fly from the tables
> ProductCategory and ProductCategoryMember.
>
> You should add a description field to the ProductCategoryMember table
> and then change the productsummary.ftl and productsummary.bsh files so
> the description field in the category detail page maps the description
> of that product for that category.

Okay after digging into this, my ofbiz awareness is like a candle that has a
hard time staying lit.

inside of..
./ofbiz/applications/order/webapp/ordermgr/entry/catalog/productsumary.ftl
this seems to be what I am looking for...

<div class="tabletext">${productContentWrapper.get("DESCRIPTION")?if_exists}

This is what I need to fix. I was hoping that this line would have been a normal
field instead of a wrapper and that there were references to
ProductCategoryMember to work from in the .ftl and in the bsh.

I understand the bean shell is where all the work has to be done. I need to open
up the ProductCategoryMember table, if the description is not blank, load in my
new field in and push the data upstream.

Now how all that gets done will be real simple months from now. Today.... Yikes!
Where to begin?

I will gladly accept any pointers to example code so that the learning can
continue, 'cause now I feel pretty stupid.

Thanks

--
Walter
 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Alexandre Gomes-5]

   This is an example of how you would get a list of rows from a table
from a beanshell script :

List productCategoryMembers =
delegator.findByAndCache("ProductCategoryMember",
UtilMisc.toMap("productId", productId, "productCategoryId",
productCategoryId));

  Then you get the first on the list (to obtain a GenericValue entity
instance) :

productCategoryMember = EntityUtil.getFirst(productCategoryMembers);

   Then you get the description field from the entity:

description = productCategoryMember.get("description");

   Then you put it in the context for upstream processing in the
productsummary.ftl template file:

context.put("description", "description");


   I hope this gets you started.

Regards,
Alex

On 6/22/06, Walter Vaughan <[hidden email]> wrote:

> Alexandre Gomes wrote:
>
> > Hi Walter,
> >
> > ProductCategoryAndMembers is a view created on the fly from the tables
> > ProductCategory and ProductCategoryMember.
> >
> > You should add a description field to the ProductCategoryMember table
> > and then change the productsummary.ftl and productsummary.bsh files so
> > the description field in the category detail page maps the description
> > of that product for that category.
>
> Okay after digging into this, my ofbiz awareness is like a candle that has a
> hard time staying lit.
>
> inside of..
> ./ofbiz/applications/order/webapp/ordermgr/entry/catalog/productsumary.ftl
> this seems to be what I am looking for...
>
> <div class="tabletext">${productContentWrapper.get("DESCRIPTION")?if_exists}
>
> This is what I need to fix. I was hoping that this line would have been a normal
> field instead of a wrapper and that there were references to
> ProductCategoryMember to work from in the .ftl and in the bsh.
>
> I understand the bean shell is where all the work has to be done. I need to open
> up the ProductCategoryMember table, if the description is not blank, load in my
> new field in and push the data upstream.
>
> Now how all that gets done will be real simple months from now. Today.... Yikes!
> Where to begin?
>
> I will gladly accept any pointers to example code so that the learning can
> continue, 'cause now I feel pretty stupid.
>
> Thanks
>
> --
> Walter
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users