On Thu, Jul 4, 2013 at 6:48 PM, Cédric Krier <[email protected]> wrote:
> On 04/07/13 18:15 +0530, Sharoon Thomas wrote: > > On Thu, Jul 4, 2013 at 6:00 PM, Cédric Krier <[email protected]> > wrote: > > > > > On 04/07/13 13:56 +0200, Raimon Esteve wrote: > > > Also I already find that nereid does too much, such features are > > > customizable or should be customizable. > > > > > > We have been removing some features into other modules before > > we move repo to tryton. In this case can you be specific ? > > For example, being depending on party. > Will look into this again and try a refactor which wont break things. > > > But I see there is a modulartity issue in nereid in such method like > > > edit_address because they return the rendered template and so it is no > > > more possible to customize it. > > > > > > > this wont be a modularity issue since the template from the local app > folder > > can substitute the entire template or just a part (block) of it. > > > > For example, nereid-checkout could overwrite the address-edit.jinja > > in nereid core. The local templates folder could overwrite that template > > the same way. The inheritance is based ont he tryton module graph of > > the installed database. > > I know that for template but what about the context used to do the > rendering? > I think each rendering method should be split into 2 methods or return > an lazy renderer that allow to customize the context. > splitting seems like a bad idea which will result in a bloat, but lazy renderer should be easy. [1] https://github.com/openlabs/nereid/issues/67 Thanks & Regards -- -- Sharoon Thomas Openlabs Technologies & Consulting (P) Limited w: http://www.openlabs.co.in m: +1 813.793.6736 (OPEN) Extn. 200 t: @sharoonthomas - We CARE for our customers
