Thread: [phpslash-users] questions about block code.
Brought to you by:
joestewart,
nhruby
From: Aric C. <gre...@pe...> - 2002-10-22 19:22:35
|
two questions: 1. I am working on a shopping cart package, and would like to have a = blocks system pretty much like what phpslash has. In fact I think it = can be exactly the same. In fact I'd like to basicaly just lift the = code from phpslash and incorporate it. At some point I may even try a = complete integration because we'd like to have basic content management. = Not sure how to go about this. But the question is, do you mind? Of = course credit will be given. 2. The block code itself. Looking at block.class and block_i.class, it = seems like the doBlock() and parseBlock() functions basicaly do the same = thing. For my purposes it looks like I dont need doBlock. In fact I = could simplify matters and just merge the two classes. Are they = separate classes just for the purpose of logicaly separating the block = logic from the block display? Why is there a getFancyBox function = instead of this being a method of the block class? Historical reasons? OK I know that's more than two questions... :) |
From: Joe S. <joe...@us...> - 2002-10-22 20:15:14
|
On Tue, Oct 22, 2002 at 12:22:05PM -0700, Aric Caley wrote: > two questions: > > 1. I am working on a shopping cart package, and would like to have a blocks system pretty much like what phpslash has. In fact I think it can be exactly the same. In fact I'd like to basicaly just lift the code from phpslash and incorporate it. At some point I may even try a complete integration because we'd like to have basic content management. Not sure how to go about this. But the question is, do you mind? Of course credit will be given. > Sounds like a good thing. The code is GPL. Mike Gifford may be able to give you a few pointers on how they've merged phpSlash with Back-End. I don't know the scope of your project but maybe a tighter integration and your shopping cart package could be a Back-End or phpSlash module. > 2. The block code itself. Looking at block.class and block_i.class, it seems like the doBlock() and parseBlock() functions basicaly do the same thing. For my purposes it looks like I dont need doBlock. In fact I could simplify matters and just merge the two classes. Are they separate classes just for the purpose of logicaly separating the block logic from the block display? Why is there a getFancyBox function instead of this being a method of the block class? Historical reasons? > I believe doBlock is now only used when the block is shown to the admin after being saved. Yes, the Block_i is separated to be a display implementation. Note that the cvs version has the admin methods separated into Block_admin.class which extends Block_i. The fancyboxes in the 0.5 series were generated on the index page. No classes. You can still create a fancybox outside the blocks. Don't know of any use anymore though. > OK I know that's more than two questions... :) |