Extendable Contribution (sub-contributions?)

[pyromosh]

Hello,

I'm fairly new to Zen Cart, but I've found it quite useful and quite extendable.

I have some ideas that I'd like to put out as a contributions, but I'm still a little fuzzy as to best practices.


First, the contribution I have already half written changes the Product Option system by adding a new Product Option Type called "Dialog".

The idea behind "Dialog" rather than have a set of radio buttons, or a text box, or a checkbox, etc; you would get a popup (light box style) form where you could give a user a more complex set of interactive controls. The user then hits "OK", the light box disappears, and the data from that form is saved to a disabled text box on the product page.

For instance - My site, I'd like to give my users the choice of picking a font for customized products. Since We have 400+ fonts, and since most people don't know what most fonts look like, we need to display what they look like, prior to the customer choosing.

There's just not enough room to do that on the product page.
So my solution is a form where the customer types some sample text, then uses a dropdown box to pick diffrent fonts, and see what they look like. A quick example of what I mean is here:
http://carlo-cards.com/fonts/fonts.php

As I said, this is 90% done. I just need some clarification as to best practices.

First, I had to modify the following files:
admin/options_values_manager.php
admin/includes/functions/general.php
admin/attributes_controller.php
admin/options_name_manager.php

I also had to modify others, but thanks to the override system, they don't need to be overwritten. They can just go in the your_template folders.

My first question is: Is there a better way than modifying those four admin files? Is there an override system for the admin folder? Or something else I'm missing? I suspect this is the only way, but I'd like to leave as small a footprint on the core files as I can.




The other thing is, I'm going through all the trouble of creating a new UI element for the Attributes system, it seems a shame to limit to picking fonts. So I'd like to make it extendable.

I'm not sure the best way to do that though.

What I'd like to do is have each dialog type be a "sub-contribution". In other words the dialog system would be a contribution, and you could plug as many or as few "sub-contribution" types as you like into it.

You could have a dialog box for picking a font, or choosing between different engine options with stats for each one, or anything you can think of. It's got the space to be interactive, but when you're done, the dialog closes, and just returns a string.

The way I think it would be best to implement this is like so:
User installs the "Dialog" contribution.
User is now able to select "Dialog" as a Product Option Type, when creating or editing Product Options.
User can now install "Font Picker" sub-contribution.
When installed, "Font Picker" will become selectable as an option value for "Dialog" option types.

I imagine the install would involve an SQL file for each sub-contribution.

This SQL file would create a new entry on the products_options_values table with an entry under products_options_values_name structured like DIALOG_$subContributionName

For instance with Font Picker, it would add "DIALOG_Font_Picker" under products_options_values_name.

This would make "DIALOG_Font_Picker" selectable under the Option Values list.

The subcontributiuon would also include a folder with the name of the contribution ("DIALOGS/Font_Picker" in this example)

When an attribute has it's value set to a "DIALOG_*" value, the system would know to look in the "DIALOGS/*" folder for the necessary php file(s) to include in the dialog box.


Does this make any sense? I feel this is kind of hard to convey. I have it basically working, I just don't think I've explained it well.

My second, questions is: where should these subfolders live? I have no idea what the "proper" place is to put a set of folders for "subcontributions".

Any help would be greatly appreciated.

[DrByte]

First, I had to modify the following files:
admin/options_values_manager.php
admin/includes/functions/general.php
admin/attributes_controller.php
admin/options_name_manager.php

I also had to modify others, but thanks to the override system, they don't need to be overwritten. They can just go in the your_template folders.

My first question is: Is there a better way than modifying those four admin files? Is there an override system for the admin folder?

There is no override support for the admin at this time.
The override support in the storefront side is intended largely to accommodate the desire for custom templates based on a theme such as Summer/Spring/Easter/Christmas/Clearance/GrandOpening/etc. Since that's not relevant to the admin there is no need for overrides.

[pyromosh]

There is no override support for the admin at this time.
The override support in the storefront side is intended largely to accommodate the desire for custom templates based on a theme such as Summer/Spring/Easter/Christmas/Clearance/GrandOpening/etc. Since that's not relevant to the admin there is no need for overrides.

Okay, your answer is definitely helpful.

I've gone back, and re-though how I was going about this mod. I've removed most of the modifications to the admin folder, and I think I may be able to remove them all. Just a question of how easy to use this mod will be in the end.

What about the second element though? Right now I've got two "add-ons" to this that would allow you to insert either a font picker or a date picker.

My current structure looks like:

/admin/includes/extra_datafiles/dialog_products_options_type.php
/includes/modules/YOUR_TEMPLATE_NAME/attributes.php
/includes/extra_datafiles/dialog_products_options_type.php
/includes/templates/YOUR_TEMPLATE/css/stylesheet_dialog.css
/includes/classes/dialogs/font_picker/
/includes/classes/dialogs/date_picker/


There's also a small SQL patch.

Only /includes/modules/YOUR_TEMPLATE_NAME/attributes.php overwrites an existing file.

My big question relates to structure.

The way I have things now, the "Core" files of this mod are:
/admin/includes/extra_datafiles/dialog_products_options_type.php
/includes/modules/YOUR_TEMPLATE_NAME/attributes.php
/includes/extra_datafiles/dialog_products_options_type.php
/includes/templates/YOUR_TEMPLATE/css/stylesheet_dialog.css

Once they and the SQL patch are installed, it adds a new option type to your admin panel called "Dialog".

You select that, and, well, nothing happens.

In order for something to happen, you need a dialog type installed. Right now, dialog types live in:
/includes/classes/dialogs/$DIALOG_TYPE_NAME/

Which works fine, but I'm not sure if it's the "correct" path to have something like that in. Can anyone point me in the "correct" direction?

Thanks again!

[DrByte]

As far as folder structure, if that's what works for you, use it for now.

Zen Cart v2.0 has a broader use of subdirectory names for decorators etc under the classes folder, and as such you may elect a different pattern when you rewrite your addon for use with the new OOP infrastructure.

[Website Rob]

Although I'm not sure of all the details, couldn't one create:

admin/includes/auto_loaders/overrides/config.dialog_products.php
- and in it put a listing of the paths & file names to be used

and would allow creating your own files and not have to touch 'core' files?

[DrByte]

That wouldn't prevent needing to edit core files to inject the new coding capabilities they're trying to add.