On Tue, Mar 20, 2012 at 9:04 PM, Lukasz Szybalski <[email protected]> wrote:
> On Mon, Mar 19, 2012 at 1:13 PM, Chris McDonough <[email protected]> wrote:
>> On Mon, 2012-03-19 at 11:04 -0700, Mike Orr wrote:
>>
>>> So it sounds like Lukasz is asking for a way to make a view with
>>> customizable output. I can see a possibility for this if the view is
>>> written to use "something" that can be overridden. I'm not sure where
>>> to go from there, or what kind of plugin mechanism would be suitable.
>
>
> I guess I'm just looking for example a hello world plugin
> (http://trac-hacks.org/wiki/HelloWorldPlugin) and how do I go about
> designing it for pyramid.
>
>
> 1. You start up your scaffold "alchemy" app and start adding plugins
> to it to help you get to a point where you start building what you
> need.

It revolves around what you mean by a "plugin". As I said, there's no
universal definition, and people have widely differing ideas about
what plugins are and what kinds of things they should do. Pyramid has
nothing called a plugin, although the word is sometimes used for its
ZCA (Zope Component Architecture) interface. It has several things
that allow you to insert functionality into an application --
includes, asset overriding, entry points, custom renderers, the
resource tree, etc -- these could all fit the basic definition of a
plugin.

> 2. How do you add /admin page that allows you to add/edit/delete
> records in database? Why wouldn't I be able to just download this
> plugin for pyarmid and enable it. Or write a plugin so I could reuse
> it in all my apps.

We (Pylons/Pyramid) have long wished for an easy-to-install CRUD
interface / admin interface. The only one that has been written is in
Ptah. FormAlchemy gives you building blocks to make such a thing.
Theoretically it would be possible to "include" a package mounted on
/admin that does this, if such a package existed.

> 3. How would one go about building a /admin page similar to trac that
> allows you to for example view a list of plugins installed "included".

That depends on what a plugin is. My first point.

As far as I know, Pyramid does not have a list of prior includes, or a
way to distinguish relevant includes (from your perspective) vs other
includes. You could write something that keeps a list of relevant
includes in 'settings'.

> "Example of how to use the  existing include() machinery to include
> some configuration that registers one or more views" is probably what
> I'm looking for exactly. I will have to research that to see how one
> would build admin page that registers views that access your database
> and allow you to add/edit/delete records. Create some docs, and
> hopefully one could use that as a example to lets say build
> "permission editing" or "auto build views based on what is in
> database"..etc

It sounds like you're on your way to building an includible CRUD
interface. Ptah may have some code you can start from, although it's
intertwined with how Ptah manages sessions/engines.

I'm not sure I would call it a plugin though. I think of it more as a
view bundle. (A collection of views, with whatever templates, routes,
models, and static files it needs.)

-- 
Mike Orr <[email protected]>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Reply via email to