On Fri, Apr 3, 2009 at 9:03 PM, Yarko Tymciurak <yark...@gmail.com> wrote:
> > On Fri, Apr 3, 2009 at 8:58 PM, Yarko Tymciurak <yark...@gmail.com> wrote: > >> On Fri, Apr 3, 2009 at 4:35 PM, Yarko Tymciurak <yark...@gmail.com>wrote: >> >>> another way to state this: partials are language from one very (too) >>> narrow use case. >>> The general case is that page CONTAINERS manage output, and decay to one >>> container per page (or the partials sort of idea that were mentioned). >>> >>> Now - controller logic is just engineering logic - implementation of >>> solution / output; >>> >>> Containers, and the protocol to connect output (URI) to a container is >>> view logic... >>> >>> This is important, because this is how outupt to one page (for example >>> for PyCon) can be collected from controller outupt from 2 frameworks (django >>> or web2py).... >>> >>> And this is where this concept shows the boundaries that are appropriate >>> (the other end of the boundary - even if you never want to combine output >>> from elsewhere, the point is still that level of separation is desireable). >>> >>> Come to think of it, another place to look is what do Yahoo Pipes do? >>> That is 3 places to look, and gather ideas: Yahoo Pipes, jsr Portlets, >>> .Net / what dotnetnuke uses to implement application containers... >>> >>> This last piece is where web2py can start: think about how to have >>> "portlets" that can (for example) be connected to web2py application output. >>> >> > >> Note what this last concept does / says: If I can have a screen >> container as a destination, then I can supply tools which are applications >> (however small) which a user / site can just install and connect - for >> example, to have a calendar on the page. What that calendar ties to (now) >> could be done thru the calendar's admin interface --- instead of >> programming. Placing the calendar, and connecting it to a receptor/container >> too can be an admin functionality. This is an important shift. >> > > And not new - dotnetnuke already does this (has for years). It would just > be new (?) to Python. I know there are some aspects of this in Plone, but > those I believe are rather less flexible than what I'm thinking of - I'm > still thinking of one page, multi frameworks putputting to (still thinking > about future of pycon site). > Also see my.msn.com for concept of site / page elements that you can move around, and their content follows. and menu items that user (or concievably admin) can use to configure thru the container. > > >> >> Let's think about this carefully, study what's out there and come up with >> a starting, simple (but appropriately functional) proposal. >> >> -y >> > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
