| # |
Jul 15th 2009, 17:23 |
Phally |
ProLoser|Work: yeah, because all those payment methods are so different, he said he needed to separate the logic |
| # |
Jul 15th 2009, 17:22 |
ProLoser|Work |
for cakephp? |
| # |
Jul 15th 2009, 17:22 |
Phally |
ProLoser|Work: what a collegue of mine did in the past.. he made a payments plugin with a ccbill_controller, a tripledeal_controller etc |
| # |
Jul 15th 2009, 17:22 |
ProLoser|Work |
no team development (outside the core) and no expanded scripts |
| # |
Jul 15th 2009, 17:21 |
ProLoser|Work |
i think it's why the selection of scripts out there is somewhat poor at times |
| # |
Jul 15th 2009, 17:21 |
ProLoser|Work |
instead of the "this code fits this need in this specific way and must be installed thusly to do that" |
| # |
Jul 15th 2009, 17:21 |
ProLoser|Work |
that way if people want more gateways, they simply create a new datasource that links into the behavior, causing more people to reuse the same scripts |
| # |
Jul 15th 2009, 17:20 |
ProLoser|Work |
so the idea of creating a set of standards that filters through a payment gateway behavior and then use your paymentgateway on your site |
| # |
Jul 15th 2009, 17:20 |
ProLoser|Work |
for instance, there are lots of datasources, and a few payment gateways, but they are all slightly tedious to setup |
| # |
Jul 15th 2009, 17:20 |
ProLoser|Work |
but more than than, making the abstract and modular |
| # |
Jul 15th 2009, 17:19 |
ProLoser|Work |
preventing scope creep |
| # |
Jul 15th 2009, 17:19 |
ProLoser|Work |
well ya |
| # |
Jul 15th 2009, 17:19 |
Phally |
and make it flexible so people can put like anything in it |
| # |
Jul 15th 2009, 17:19 |
ProLoser|Work |
anywho, i like giving up the tools, and letting people choose how and where to apply them |
| # |
Jul 15th 2009, 17:19 |
Phally |
right, that is a nice alternative use of such a thing |
| # |
Jul 15th 2009, 17:18 |
ProLoser|Work |
or abstractly measured pricing |
| # |
Jul 15th 2009, 17:18 |
ProLoser|Work |
there are also aspects of a cart that is just a pain and a h alf to hack out of a prebuilt one, such as composite products |
| # |
Jul 15th 2009, 17:18 |
ProLoser|Work |
but you cannot checkout or buy anything from them |
| # |
Jul 15th 2009, 17:17 |
ProLoser|Work |
Phally: the intention is that we haven't seen it so we don't know, but the best ideas are the ones no one's done before |
| # |
Jul 15th 2009, 17:17 |
Phally |
the paginator helper is loaded in the controller when something is paginated |
| # |
Jul 15th 2009, 17:16 |
Phally |
but look at the paginator i.e. |
| # |
Jul 15th 2009, 17:15 |
ProLoser|Work |
or only having a checkout screen |
| # |
Jul 15th 2009, 17:14 |
ProLoser|Work |
ya, i like the tools approach, and offering the ability to bundle them together and attach em, which would be 1 big plugin |
| # |
Jul 15th 2009, 17:14 |
ProLoser|Work |
however i figure there are so many prebuilt cart apps out there, even ones with modules, that what's the point of making another one? the one thing you don't get in those apps is the ability to build a cart on top of your own application, instead of hacking someone elsess |
| # |
Jul 15th 2009, 17:13 |
Phally |
i think you should give the user a set of tools |
| # |
Jul 15th 2009, 17:13 |
ProLoser|Work |
while he would rather go a more drupal/modular route and create a base app that you merely design plugins for |
| # |
Jul 15th 2009, 17:13 |
ProLoser|Work |
i would rather give people a set of tools that they can attach to their app |
| # |
Jul 15th 2009, 17:13 |
ProLoser|Work |
we're trying to make very versatile solutions |
| # |
Jul 15th 2009, 17:12 |
ProLoser|Work |
so you /would/ recommend placing it all in plugins? |
| # |
Jul 15th 2009, 17:12 |
Phally |
*take |
| # |
Jul 15th 2009, 17:12 |
Phally |
and how much effort does it make to create three folders and place a file in it? |
| # |
Jul 15th 2009, 17:11 |
Phally |
well you would have a good level of separation and packaging through the plugins |
| # |
Jul 15th 2009, 17:10 |
ProLoser|Work |
and would it be worth it to wrap solely a component in a plugin? |
| # |
Jul 15th 2009, 17:10 |
ProLoser|Work |
is there a reason why a plugin manager server would be made instead of one that also serves out helpers/components/behaviors? |
| # |
Jul 15th 2009, 16:48 |
ProLoser|Work |
*crickets* |
| # |
Jul 15th 2009, 16:47 |
techno-geek |
ProLoser|Work, see this post http://www.pseudocoder.com/archives/2009/05/29/connecting-cakephp-plugins/ |
| # |
Jul 15th 2009, 16:46 |
ProLoser|Work |
or /that/ lol |
| # |
Jul 15th 2009, 16:46 |
techno-geek |
and it was in the form of the cakephp plugin conventions? |
| # |
Jul 15th 2009, 16:46 |
ProLoser|Work |
on their own they don't make sense techno |
| # |
Jul 15th 2009, 16:46 |
techno-geek |
what if there was a standardized way of package, managing, and releasing code? |
| # |
Jul 15th 2009, 16:46 |
ProLoser|Work |
although we may want to digress to the original point of the arguments |