Plug-in with views?

[jaminv]

Can a plug-in have its own views?  I'm a little new to Joomla/VM programming, but quite versed in PHP and design patterns.

It seems to me that plug-ins are a little bit of M,V, and C all wrapped into one.  This is especially true when they connect with the database directly, output html, and output some pretty intensive JS (JQuery) as well.  Example being stockable.php.  I'm working on an extension/improvement/debugging of that plug-in.

What I'd really like is multiple views.  I can absolutely create a function for each view and call these functions in a switch based on a plugin parameter, but...  My plugin file is quickly becoming a giant mess and I'm only one view in.  I want a total of 4 views.  Then, I have to include a whole bunch of documentation on how to CSS template my views because they're pretty inflexible, and I have to also try to make sure the HTML tags are as flexible as possible to allow such templating.  If only I could create 4 override-able views and call them from my plug-in...

I'm sure there's a way, but I'm not 100% sure what that is.  I'm also pretty sure I could figure it out one way or another, but I want to make sure I'm following best practices in doing so.

What would be even better is if, on top of the ability to override views, people could also add views.  If they didn't like any of my views and wanted their own, or if they liked all of my views and wanted to add some additional views, that would be the true key to an extensible plugin.

Can anyone help point me in the right direction?

--Jamin

[PRO]

are you talking about the actual plugin output? like the way the custom fields look?
why not 4 different plugins?



OR , are you talking about different layouts for products?

[jaminv]

What I'm talking about is 4 different layouts for the same content.  Currently (bugs aside), the stockable plugin displays custom children in a single, very rigid, format: a drop-down list.  It doesn't allow a lot of options, either.  If you want radio buttons instead (I'm sure quite a few people do), then I guess you get to recode everything.  Personally, I want to list all of the items in a table with a "add to cart" button for each.  Same content: 3 different views.  I can also envision at least one other way to arrange the same data.

On top of being still quite rigid, 4 seperate plugins sounds like an aweful lot of duplicate code.

The benefit of views, of course, is being able to override them.  So if you like a specific view but want to tweak it a little, you can do that without having to recreate the entire plugin.

The more I'm looking, however, the more I'm finding that it looks like plugins just weren't designed like this.  A few possible ways I'm thinking this might work is:  Having plugin view classes that could be overriden from another plugin (in the essence of how you can override a model, view, or controller - I just check for the existance of a class before requiring it, if a plugin already created it, then it already exists), explicitly checking for the existance of a file in templates/<template>/html/<some path>, or having 4 seperate plugins that inherit from the same parent and packaging them together.   All of these would work (theoretically), but none are particularly elegant.

Of these, I suppose a base class that does all the heavy lifting and plugin view classes that do little else but return HTML from a method - seems like the most elegant.  It would significantly reduce the barrier to creating a new custom view for the plugin, or modifying a view that already exists.  I'm not sure how this would work exactly, however.  There's not a lot of plugin documentation that deal with object hierarchies.

Thoughts?

[PRO]

then yes, you  are going to have to do a switch based on the parameter

[jaminv]

Really?  Is there no better way?  The further I got into doing that way, the more I felt like it was a really bad way of doing things.  And then there's the concept of "there's no way I can please everyone" that makes templating so attractive.

Would inheritance not work?

[Milbo]

You can add your own views, using the trigger onVmAdminController for example

[jaminv]

Either you don't understand what I'm trying to do, or I don't understand what you're getting at.

I'm building (improving) a custom field plugin, derived from vmCustomPlugin.  Instead of hard-coding the outputs into the plugin class, I'm looking for some way to allow templating of the output based on data I would send to the template. 

If this would work via the method you're saying, please elaborate.  Based on what I'm reading, however, I'm not seeing the connection.  The docs say I would have to derive from vmExtendedPlugin to use onVmAdminController?  Would I add another plugin class or something?  Please help me connect the dots.

[jaminv]

What I've discovered I can do is create one plugin for the base class, and additional plugins that inherit from that base class.  It's slightly less than ideal, the base class has to be enabled and ordered before any inheriting class, and the base class still shows up in the plugin drop-down on the back end despite not being particularly useful.  However, it does work, and seems a heck of a lot better than a bunch of duplicate code across several plugins.

Doing them as seperate plugins seems like a good way to do it, because it allowed for plugin parameters specific to the view.  Seemed a lot better than a bunch of parameters with comments like "only applies to ______ view".

I don't know, might not be the best way to do it.  I'm definitely open to suggestion.  At the very least, I can document it well and provide concise installation instructions.  In my experience, doing something funky with great documentation is better than coding something perfectly with no documentation...

Thanks for the help so far.  I'm definitely willing to listen if you have any other ideas.

Jamin

[Milbo]

Afaik you cant use templates in plugins. Maybe in j1.7, anyway you can create your own structure, with a controller and all that. But plugins are normally just one file, yes. Modules btw have views.

[jaminv]

Afaik you cant use templates in plugins. Maybe in j1.7, anyway you can create your own structure, with a controller and all that. But plugins are normally just one file, yes. Modules btw have views.

That's interesting.  I thought of that, but it seems that the controller->view interaction is largely based on the folder structure of components or modules, and plugins do not share that structure.   There's nothing in the controller that says "here is where my view is located" (which makes sense, because it might instead load it from a template).  I'm just not sure how I'd organize a plugin to support this kind of interaction, and I have yet to find a single example of someone trying to do that.  My searches have been fairly fruitless, and as far as I can tell, no one's really even tried to do something like this.

As far as I know, my custom field has to be a plugin, and can not be a module.

Thanks for the ideas though.  I'm going to keep looking, but I don't want it to hold back my development.

Jamin

[Milbo]

Maybe you want to create a module, using a plugin?

[jaminv]

Maybe you want to create a module, using a plugin?

Interesting thought.  I'll look into that.

Thanks.

Jamin