[Zope-dev] Re: [Repoze-dev] repoze.bfg
Malthe Borch wrote: Chris McDonough wrote: I've been working on a new web framework named (provisionally) repoze.bfg. This looks very interesting; I'd be curious to see if this could be useful for Vudo. I'd like it very much if Vudo could sit on top of a more general framework (not just the Zope 3 libraries). Early on, the idea was that this could be Grok, but it quickly turned out that Grok makes too many assumptions for our use. I recently pasted a basic Pylons application and it gives you something that I think would be attractive in a Zope/Vudo/Bfg-based setup: A canonical directory structure, e.g. ./templates ./routers ./config etc. (can't remember the details) Sure. I think one of us (maybe Paul?) signed up to write a PasteScript template to lay out a directory structure something like this. We don't currently provide an easy way to serve out a static directory full of content. We'd need to add that (or decide not to add it in favor of letting a separate resource server serve the static stuff). Perhaps this could benefit the following scenario: -- Set me up with a new Zope/Vudo/Bfg-application and give me some starting points. If Bfg can provide the lower layer, then I think Vudo will be great for providing the higher layers, e.g. -- skinning -- content types and widgets -- authoring -- admin Sounds good to me. The plans are to keep BFG mostly policy-agnostic save for the very basics (graph traversal, a default templating language, and a calling and response convention for views). I had planned to create another package named repoze.lemonade which: - Wired in ZODB - Defined base classes for folderish and leafish types. - Had an object add/remove/move event model. - Did indexing of content. It sounds like Vudo could either build on top of that or just *be* that. It might be better to continue layering stuff, I suppose, without going straight to the content management layer. Would it be appropriate for Vudo to build on something like that? What would Vudo need out of a framework? - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Repoze-dev] repoze.bfg
Malthe Borch [EMAIL PROTECTED] writes: On Vudo, the view is always a layout. It's then up to the layout to provide regions in which you can plug in a region content provider. Typically, you'd plug in at least the following: -- Title provider: Renders the title of the page (in title/title) -- Content provider: Renders the content of the page as widgets There are many more options to this scheme. You could plug in a portlet manager, or a viewlet manager or a global navigation. Someone mentioned Vudo to me last week. I said that I was tempted to write an extension to Grok that lets you create a grok.Layout template that maybe is inherited throughout your whole site if you don't specify otherwise, and then a grok.View on an object would just generate content for the main pane inside of that layout, and viewlets could keep working like they do today but fill in other parts of the layout. This is kind of how people look to be doing things today with the viewlets revolution that's going on in Grok land; look at: http://svn.zope.org/Grokstar/trunk/src/grokstar/blog.py?rev=87483view=auto and note how many of the grok.View objects are specifying the same dratted template, over and over again, and then rely on viewlets to actually fill in the varying parts of each page that change with the content. It struck me as a situation that is just crying out for a grok.Layout local utility that provides the template everywhere under a part of a site automatically, so that the grok.template(...) declaration does not have to get repeated so incessantly. It really looks to me like Grok best-practices are evolving towards a layout-centric, rather than a macro-centric, approach, and that something like the Vudo approach would make this all easier to manage. Do I sound on-target, or like I'm missing something? -- Brandon Craig Rhodes [EMAIL PROTECTED] http://rhodesmill.org/brandon ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Repoze-dev] repoze.bfg
Chris McDonough wrote: I had planned to create another package named repoze.lemonade which: ... - Did indexing of content. What were you thinking of for indexing? Just catalog stuff? More general? There's been a tension in the opencore stuff with the catalog, mostly that it's easy to setup and use for things, but it doesn't really work for things outside of the ZODB. Or, I guess theoretically you could catalog things not in the ZODB, but it's never happened. That said, there's a real need for cross-system indexing of different kinds. There's text search indexes, but other kinds of more strict indexes also make sense. It would be very handy to have an index that wasn't tied to the ZODB, a database, or anything else. (It could be implemented using the ZODB or a database, of course.) -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Repoze-dev] repoze.bfg
Ian Bicking wrote: Chris McDonough wrote: I had planned to create another package named repoze.lemonade which: ... - Did indexing of content. What were you thinking of for indexing? Just catalog stuff? More general? I was considering just using zope.index but I haven't really thought much about it yet. There's been a tension in the opencore stuff with the catalog, mostly that it's easy to setup and use for things, but it doesn't really work for things outside of the ZODB. Or, I guess theoretically you could catalog things not in the ZODB, but it's never happened. IMO, mostly it's a matter of deciding what index and catalog means for searching. If you only need full-text search, some indexing systems are totally inappropriate. Likewise, if you only need field indexes that match just one particular value, it's sometimes vastly simpler just to come up with your own system based on, e.g. a relational table, than it is to try to use somebody else's indexer or catalog. That said, there's a real need for cross-system indexing of different kinds. There's text search indexes, but other kinds of more strict indexes also make sense. It would be very handy to have an index that wasn't tied to the ZODB, a database, or anything else. (It could be implemented using the ZODB or a database, of course.) Xapian seems like a good choice too. It has its own persistence mechanism and reasonable Python bindings (although from experience maybe slightly memory-leaky). - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Repoze-dev] repoze.bfg
Chris McDonough wrote: There's been a tension in the opencore stuff with the catalog, mostly that it's easy to setup and use for things, but it doesn't really work for things outside of the ZODB. Or, I guess theoretically you could catalog things not in the ZODB, but it's never happened. IMO, mostly it's a matter of deciding what index and catalog means for searching. If you only need full-text search, some indexing systems are totally inappropriate. Likewise, if you only need field indexes that match just one particular value, it's sometimes vastly simpler just to come up with your own system based on, e.g. a relational table, than it is to try to use somebody else's indexer or catalog. They are similar in that they both need to get information about updates, and a way to reindex. Full text search can be a little lazier, as being 100% up-to-date isn't such a big issue. That said, there's a real need for cross-system indexing of different kinds. There's text search indexes, but other kinds of more strict indexes also make sense. It would be very handy to have an index that wasn't tied to the ZODB, a database, or anything else. (It could be implemented using the ZODB or a database, of course.) Xapian seems like a good choice too. It has its own persistence mechanism and reasonable Python bindings (although from experience maybe slightly memory-leaky). Yes, once you get the documents into it. Actually, it's really a many-to-many notification system that's needed. We have one that needs documenting and review (http://www.openplans.org/projects/cabochon/project-home) but while it handles notifications and events (as do several other systems), that doesn't cover reindexing the site. And then you also need a set of useful endpoints, but those can grow over time. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Repoze-dev] repoze.bfg
Ian Bicking wrote: Chris McDonough wrote: There's been a tension in the opencore stuff with the catalog, mostly that it's easy to setup and use for things, but it doesn't really work for things outside of the ZODB. Or, I guess theoretically you could catalog things not in the ZODB, but it's never happened. IMO, mostly it's a matter of deciding what index and catalog means for searching. If you only need full-text search, some indexing systems are totally inappropriate. Likewise, if you only need field indexes that match just one particular value, it's sometimes vastly simpler just to come up with your own system based on, e.g. a relational table, than it is to try to use somebody else's indexer or catalog. They are similar in that they both need to get information about updates, and a way to reindex. Full text search can be a little lazier, as being 100% up-to-date isn't such a big issue. I'd typically handle the info about updates bit by sending an event (which I suspect cabochon is all about). That said, there's a real need for cross-system indexing of different kinds. There's text search indexes, but other kinds of more strict indexes also make sense. It would be very handy to have an index that wasn't tied to the ZODB, a database, or anything else. (It could be implemented using the ZODB or a database, of course.) Xapian seems like a good choice too. It has its own persistence mechanism and reasonable Python bindings (although from experience maybe slightly memory-leaky). Yes, once you get the documents into it. Actually, it's really a many-to-many notification system that's needed. We have one that needs documenting and review (http://www.openplans.org/projects/cabochon/project-home) but while it handles notifications and events (as do several other systems), that doesn't cover reindexing the site. And then you also need a set of useful endpoints, but those can grow over time. Stuff that I'm not sure about above: many-to-many notification system reindexing the site That said... I guess what you're saying is that it's hard to send an event that makes it clear what needs to be done as a result of the event being sent. In the case where you have a content node that holds data, that node would be attched to the event. it's pretty clear that you need to do.. that thing changed, and the indexing code needs to inspect it and reindex whatever indexes you've got sitting around that are willing to index data about those types of nodes. In the case where you need to deal with the simultaneous case that some row in an RDB was changed, it's not quite as clear. What does it mean and who should do what with that event? It's all policy at that point. I'm not sure any framework helps. It's just block-and-tackle event reception and reaction, do the needful, isn't it? - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
