Jesse,
Yes, I get it. It's a nice idea, but it's also kind of complicated, at least i
my case.
I'll have several ProductCategories, each with very distinct specifications,
like "bar code scanners", "thermal printers" and "wireless LAN infrastructure".
All Products in a ProductCategory are similar to each other, but can be
completely different from the other ProductCategories.
So, if one of my customers needs to find, for example, a barcode scanner with
laser technology, the query would be like:
SELECT * FROM Product WHERE ProductCategory=? AND xpath('specifications',
'engine/technology/text()') = 'laser';
This is a simple example, but you can imagine if we add more "filters" to this
search...
Besides generating the HTML form for Product creation and modification, I can
also use the XML template (stored in the ProductCategory) to generate these
search forms on the website. I can create product comparison tables easily with
this XML structure...
Best regards,
Flavio
On Jan 15, 2013, at 8:33 AM, Jesse Tayler <[email protected]> wrote:
> not to throw a wrench,
>
> but I would NOT store XML data but rather,
>
> I would use a key-table design where you can simply add arbitrary keys to
> things like this using queries and relationships.
>
> I once did a system for restaurant menus that had to understand the type of
> object (salad) would have a choice of dressing, but a caesar would not and a
> potato would have a choice of other things or whatever else. There were
> structures, but also an exception to every rule really. Kind of a challenge.
>
> basically, I'd watch out for putting structured data into the database and
> would suggest considering a flat table structure instead.
>
> you'd likely still want custom components to handle your UI because it sounds
> important, but I would just consider how a database can store data that is
> unformatted and unstructured and I'd add the xml structures to it at another
> layer.
>
> hope that helps!
>
>
> On Jan 15, 2013, at 7:18 AM, Flavio Donadio <[email protected]> wrote:
>
>>
>> On 13/01/2013, at 07:12, Paul Hoadley wrote:
>>
>>> I suppose it depends how frequently you expect the template XML to change,
>>> if at all, and whether you envisage changing it on the fly, or if you could
>>> just restart the application to pick it up from properties or a text file.
>>> Never changes? You could use text files (in Resources, or downloadable
>>> from somewhere, say S3) that are picked up during application
>>> initialisation. Changes frequently and is user-editable? Store it in the
>>> database—perhaps an XMLTemplate entity, one for each template type. So
>>> many options.
>>
>> Yea, Paul. I am inclined to store the template XML in the database. Since
>> the template is the same for every product in a given category, I am going
>> to store the template in a property of the ProductCategory entity.
>>
>> The template will change from time to time, especially when new products
>> bring different features that need to be included in it.
>>
>> But my question is: how do you guys recommend that I do to:
>>
>> 1. Generate the HTML form; and
>>
>> 2. Insert/update data in the XML so I can store it in the entity.
>>
>> I am almost certain that I will need a custom component for this.
>>
>>
>> Regards,
>> Flavio
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
