Can I do this with Composr?
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
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,
Catalogues are not designed for logic-based applications. For that, you'll need a programmer.
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,
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.
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.
1 guest and 0 members have recently viewed this.
