viagra dosage 100mg
I was quite happy with the way that the plugin system worked out in Vanilla 1. My bastardized version of delegation was able to solve a lot of problems that plugin developers would have otherwise faced. A big part of the problem with plugins in Vanilla 1, though, was the fact that I was never really sure *where* a plugin developer might want to plug into my code. Furthermore, the theory behind the functionality was something that novice developers had a hard time wrapping their minds around. The framework was difficult to understand, and so was the method for adding to it.
So, up until now I haven’t thought about plugins/addons/extensions for Garden in any way. I just wanted to make a tight, easy to understand, MVC framework with a nicer-to-use database layer. I think I’ve pretty much got (at least the base of) that working. So it is time, once again, to turn my thoughts to how the hell others are going to add on to my framework without actually changing my code.
I’ve read through various different books on design patterns that could be used (observer pattern, decorator pattern) and different ideas like using reflection as a plugin methodology. I’ve even just gone googling and found mind-twisting discussions like .
No matter how much I read (and sometimes fail to understand), I keep coming back to the same two issues:
1. It needs to be dead simple so even the most novice PHP programmer can do it without even flinching.
2. How the hell do we insert a plugin at an arbitrary place in a mixed php/html template without putting hooks directly in there?
So, I’m kind of stuck. I want to use some neat new ideas, but #1 makes me think I shouldn’t bother. And as for arbitrary html placement – I should just forget about it – accept the limitations of the language and work on more pressing issues.
viagra dosage
I think I’ve got it. It’s a little different than the way extensions worked in Vanilla 1, but I think it will be way more flexible and probably even easier to write than before.
