in my experience, what you describe ultimately has a lot of performance
issues due to database bottlenecks and complicated caching .
i could be wrong , but i think you're overthinking this. why try to
integrate multiple "views". why not deconstruct your views into partials
and a code library.
you can do a lot of "partials" with templates. if you're using mako, just
create a partials directory and either include them or use them as
functions in a namespace. you should make them as dumb as possible - have
them just operate on python dicts / json objects, or offload some work into
them (mako lets you run raw python in the templates ) you could try to
aggressively preload data for the templates in the views -- it would be
easier to deal with caching and stuff here.
with an approach like this, your views would dictate something like:
class view_factory(object):
def my_view(self):
self.request.template_data = {
'contact_form' : { dict }
}
templates/admin/customer/edit.mako
- include templates/partials/profile.mako
- profile( request.tempalte_data['contact_form'])
templates/customer/profile/edit.mako
- include templates/partials/profile.mako
- profile( request.tempalte_data['contact_form'])
templates/partials
- profile.mako
def profile( dict ):
form logic
you could also consider an approach where everything is javascript driven.
you could render some initial data within pyramid, and have something like
backbone.js or moustache do the on-screen renderings + api communication.
On Thursday, November 8, 2012 6:28:38 PM UTC-5, Marten wrote:
>
> Performance doesn't have priority. It's a typical web application with
> some database queries, some forms with input validation, but no heavy
> calculations, so even outdated servers could handle hundrets of concurrened
> requests.
>
> My focus is rather on reusing code. Lets say I have an "applet" to edit
> contact details. There will be a read-only view and a form to edit with
> some input validation. This sub-application shall be reused in different
> contexts.
>
> For example an administrator would use it through the URL
> /customer/1234/edit and the container might be part as a tab of a
> surrounding container where other tabs contain lists of his invoices, login
> history and such.
>
> The enduser would access it through /my-details/edit, being part of a
> dashboard along with fancy graphs, buttons to order new products and
> whatever.
>
> Doing that from scratch would mean, that all of the inhouse routing and
> view functionality of pyramid would be pretty useless and I would degrade
> it to a database pool with ORM and manually call renderers. I can't imagine
> that I'm the first to master this challenge.
>
> On Thursday, November 8, 2012 11:30:40 PM UTC+1, Jonathan Vanasco wrote:
>>
>> in my opinion there is no best-practice to handle this. it all depends
>> on how you want to structure the application for ease-of-development vs
>> where you're willing or unwilling to take performance hits.
>
>
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/pylons-discuss/-/3K8_uNp4EHAJ.
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.
