# |
Jul 17th 2009, 09:26 |
ProLoser|Work |
you were working on something like that in the beginning, no? |
# |
Jul 17th 2009, 09:26 |
techno-geek |
custom plugin designing api? |
# |
Jul 17th 2009, 09:25 |
ProLoser|Work |
did we let go of that in exchange for a common data array? |
# |
Jul 17th 2009, 09:25 |
ProLoser|Work |
or whatever it was |
# |
Jul 17th 2009, 09:25 |
ProLoser|Work |
what about the custom plugin designing api |
# |
Jul 17th 2009, 09:25 |
ProLoser|Work |
i remember that |
# |
Jul 17th 2009, 09:25 |
techno-geek |
*anywhere |
# |
Jul 17th 2009, 09:25 |
techno-geek |
You already forgot our discussion the other day, when I said all of the plugins can be used anyway |
# |
Jul 17th 2009, 09:24 |
ProLoser|Work |
which made no sense to me |
# |
Jul 17th 2009, 09:24 |
ProLoser|Work |
techno-geek: iunno, all i saw was some of your triggers code and was concerned we'd have to start using that in our code |
# |
Jul 17th 2009, 09:24 |
techno-geek |
you are like moving in reverse on our whole convo :P |
# |
Jul 17th 2009, 09:24 |
ProLoser|Work |
i just wanted the 'base app' to be the plugin as a whole |
# |
Jul 17th 2009, 09:24 |
ProLoser|Work |
oh the triggers aren't for that? |
# |
Jul 17th 2009, 09:24 |
techno-geek |
just worry about the re-usable parts we are working on |
# |
Jul 17th 2009, 09:23 |
techno-geek |
ProLoser|Work, you need to let that go. you will never see the event triggers I designed :D |
# |
Jul 17th 2009, 09:23 |
ProLoser|Work |
one of the talks goes over using the already existing built-in triggers |
# |
Jul 17th 2009, 09:23 |
ProLoser|Work |
but i don't want to design a 'base app' or set of custom triggers |
# |
Jul 17th 2009, 09:23 |
ProLoser|Work |
i'm fine with packaging everything in plugins |
# |
Jul 17th 2009, 09:22 |
ProLoser|Work |
techno-geek: bah that i was assuming we'd do |
# |
Jul 17th 2009, 09:22 |
techno-geek |
ProLoser|Work, how do you feel about adding a Helper that handles the display of $this->getOrderDetails() array? |
# |
Jul 17th 2009, 09:22 |
markstory |
would be a bitch if you had to sprinkle it. |
# |
Jul 17th 2009, 09:22 |
ProLoser|Work |
and then you can pull out the parts you want |
# |
Jul 17th 2009, 09:22 |
ProLoser|Work |
you know, putting em all into 1 cart plugin |
# |
Jul 17th 2009, 09:22 |
markstory |
and its a plugin. |
# |
Jul 17th 2009, 09:22 |
markstory |
debug kit is just a component, 3 helpers and a View class as far as 'code' is concerned. |
# |
Jul 17th 2009, 09:22 |
ProLoser|Work |
plugins is not something i've had a huge problem with, i've been toying with the idea of packaging them as components/behaviors/helpers into a plugin since day 1 |
# |
Jul 17th 2009, 09:21 |
ProLoser|Work |
techno-geek: i have, i'm not disagreeing |
# |
Jul 17th 2009, 09:21 |
techno-geek |
P |
# |
Jul 17th 2009, 09:21 |
techno-geek |
ProLoser|Work, you need to read up in the book on plugins |
# |
Jul 17th 2009, 09:21 |
markstory |
that's the idea. |
# |
Jul 17th 2009, 09:21 |
ProLoser|Work |
like from i /thought/ i came across in the media plugin |
# |
Jul 17th 2009, 09:21 |
markstory |
ProLoser|Work: yes |
# |
Jul 17th 2009, 09:21 |
ProLoser|Work |
is it possible to have a plugin with all components/behaviors/helpers only and to use those on other parts of your app? |
# |
Jul 17th 2009, 09:21 |
_nate_ |
and tar + copying is the Lesser Satan of code reusability |
# |
Jul 17th 2009, 09:20 |
markstory |
too many symlinks. |
# |
Jul 17th 2009, 09:20 |
markstory |
running the tests when files are sprinkled is a pain. |
# |
Jul 17th 2009, 09:20 |
ProLoser|Work |
why maintain? cuz of the test-cases? |
# |
Jul 17th 2009, 09:20 |
markstory |
and makes it easier for me to maintain. |
# |
Jul 17th 2009, 09:20 |
markstory |
well it makes the code easier for other to get and use. |
# |
Jul 17th 2009, 09:20 |
ProLoser|Work |
what was the reason you put your helpers in plugins? |
# |
Jul 17th 2009, 09:19 |
markstory |
instead of download tar, sprinkle files. |