I'd like to build a website w/ a page building out a form utilizing the catalogue system. The form would be used to generate pricing (for the purposes of comparison). The catalouges would be interlinked as shown below. Essentially the goal is to determine if purchasing a dining plan would be worthwhile. To do that I want to build a catalogue of menus with menu items and their prices. The next step would then to be compute the daily/per person dinining plan cost, mulitple across the number of nights stayed, and then compare it if you were paying out of pocket (with or without discounts).

Your documentation for the catalogue system is somewhat good, but using it to build out logic-based applications isn't as well documented (or I'm not finding it...totally posssible). What do you think? Can this be done?

parks
    parkid
    parkname
    lastverification
    lastupdate
resorts
    resortid
    resortname
    lastverification
    lastupdate
Locations
    lid
    locationname
    type (t/c/q/s/u/e) table/counter service/quick service/signature/unique/special event
    loctype (p/r)
    parkid
    resortid
    lastverification
    lastupdate
menu
    menuid
    menuname
    menutype (b/l/d/s/e/f/p/n) breakfast/lunch/dinner/special/event/firework/party/late night
    lastupdate
    lastverification
    itemlistid
    lid
    diningplanaccepted (y/n) yes/no
itemlist
    itemlistid
    itemname
    price
    eligblediningplan diningplantype (qs/dp/dd) quick service/dining plan/disney dining plan
    menutype (b/l/d/s/e/f/p/n) breakfast/lunch/dinner/special/event/firework/party/late night
    shareditem (y/n) yes/no
    eligblefordiscount
    maxdiscountamount
    lastupdate
    lastverification
discounts
    did
    discountname
    discountamount

Hi mwilson,

Your documentation for the catalogue system is somewhat good, but using it to build out logic-based applications isn't as well documented (or I'm not finding it…totally posssible). What do you think? Can this be done?

Catalogues are not designed for logic-based applications. For that, you'll need a programmer.

Chris Graham said

Hi mwilson,

Your documentation for the catalogue system is somewhat good, but using it to build out logic-based applications isn't as well documented (or I'm not finding it…totally posssible). What do you think? Can this be done?

Catalogues are not designed for logic-based applications. For that, you'll need a programmer.

From “Post #4266”, 1st Jun 2018

What would that entail? I've done some development work in the past.

Great! .

Ok, well the first step honestly is to forget about catalogues. There's a warning about trying to push them too far in the tutorial – while it's possible to customise the code, it's much more trouble than it's worth.

There are quite a few development-orientated tutorials you can read over, and the Code Book.

First I'd decide whether you are truly making a CRUD module (Create Update Delete module, of which catalogues is an example), or just want a form.

If you want a CRUD module then looking at the non-bundled iotds addon's code would give a good idea on how to make a fairly simple one.

If you just want a complex contact form, the Decision Tree system may be your best bet. You can see how the contact feature we use on this website is implemented using a Decision Tree:
https://github.com/ocproducts/composr/blob/master/pages/minimodules_custom/contact.php
Essentially it lets you network together various easily-generated forms, gathering data, and directing you to a terminus node. The terminus may be inside the tree (e.g. sponsor in the above example), or it may be a totally different URL (e.g. pointing to support ticket input in the above example, e.g. for upgrade).

In your case you'd need to add in some extra logic so that when you get to the end of the tree it runs the calculation code and displays the result. To keep things simple you may want to put that in a separate minimodule, so you can develop and test it separately from the Decision Tree form-input/flow code.

Oh and the decision tree system actually uses the Composr fields system, which is also used by catalogues. So you have very similar input field control.

Is there a cap on how many separate minimodules you can have running btw, Chris?

Dilano said

Is there a cap on how many separate minimodules you can have running btw, Chris?

From “Post #4692”, 26th Sep 2018

No, but if you have hundreds within a single zone you may see some performance degradation, mostly depending on your disk speed. I haven't run any tests with very large numbers.