Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #1426 (closed defect: fixed)

Opened 12 years ago

Last modified 11 years ago

ToscaWidget integration

Reported by: fredlin Owned by: mramm
Priority: highest Milestone: 2.0
Component: TurboGears Version: trunk
Severity: major Keywords: ToscaWidget
Cc: alberto

Description (last modified by mramm) (diff)

Since ToscaWidget? pylon middleware's response is not used in tg2,

We need support for ToscaWidget? integration with tg2.

Attachments

validate.patch Download (927 bytes) - added by alberto 11 years ago.
root.py Download (490 bytes) - added by alberto 11 years ago.
index.html Download (1.7 KB) - added by alberto 11 years ago.
widgets.diff Download (2.0 KB) - added by alberto 11 years ago.

Change History

comment:1 Changed 12 years ago by mramm

  • Owner changed from anonymous to alberto

Any suggestions for the best way to integrate toscawidgets into tg2

comment:2 Changed 12 years ago by fredlin

comment:3 Changed 12 years ago by mramm

We can also throw out the current error handling mechanism of tg2, in favor of something more toscawidgets friendly.

comment:4 Changed 12 years ago by alberto

  • Status changed from new to assigned
  • Priority changed from high to normal

I'm working on this branch on a new interface for tyhe HostFramework? which should make stacking and configuring TW's middleware much easier.

Regarding the @widget decorator, It might not be needed at all :) I'm also working on an experimental way to include resources in the page using lxml which is giving excellents results in an app I'm using it in. It makes the controller code *much* cleaner (no widget imports whatsoever) and spearates better the "V" from the "C" since widgets can be imported directly in the page template. More on this in this  thread

Regarding validation, the current validate() decorator for Pylons can be used, although it validates directly the request params (not the arguments of the controller method a la TG style).

To better mimic the behaviour of TG's validate decorator which validates the function's arguments I think the easiest would be to write a "real" function wrapper that did the validation instead of doing it in a controller's private method since the implementation is easier and could even be used outside TG.

Yep, this is more or less the implementation I did during the sprint ;) Sorry for reviving a past discussion but, after thinking about it more closely (and trying to implement the alternative), I believe it'd be the simplest with no serious drawbacks (as long we use the "decorator" module to copy the method's signature and __dict__).

Alberto

comment:5 follow-up: ↓ 6 Changed 12 years ago by mramm

Thanks alberto.

I'm not opposed to using "real" decorators, but we need to think carefully about that since it would make the order of the decroators very important (if expose isn't one the outside, it would decorate the internal "wrapped" function) and could cause unexpected problems for users.

We could copy the decoration object along to the wrapped function, but that could have unexpected consiquences if there were an expose before AND after validate. But I'm not sure that's a use case we should support anyway.

comment:6 in reply to: ↑ 5 Changed 12 years ago by alberto

Hi Mark,

Replying to mramm:

Thanks alberto.

I'm not opposed to using "real" decorators, but we need to think carefully about that since it would make the order of the decroators very important (if expose isn't one the outside, it would decorate the internal "wrapped" function) and could cause unexpected problems for users.

Order of decorators has always been important since there are actions which logically need to be done before others, blurring this fact is unnatural and will only lead to confusion IMO.

I think too much emphasis is being put on making our decorators behave differently than all the rest. While it does make sense for "expose" to work this way, since it's only syntactic sugar for achieving the same effect as something like:

def func():
    pass
func.content_negotiators.append(decorator_args)

making *all* decorators behave this way and leave the real work to some private method in the controller's base class is just ridiculous IMHO.

We could copy the decoration object along to the wrapped function, but that could have unexpected consiquences if there were an expose before AND after validate. But I'm not sure that's a use case we should support anyway.

I don't see any benefits in supporting that... what would be the semantics of it anyway? I think that stating in the docs that all the "expose" stack should be after the rest of the decorators is enough.

Keep in mind that forcing this style on all decorators also prevents the use of "thirdparty" validators with TG's funky controller methods, for example, the same reasoning prevents using pylons' beaker_cache (just to name one, in fact, all of Pylons' decorators also use the Schimionato's decorator module hence will be unusable if we further pursue this idea).

Well, that said, here's the validate decorator I wrote plus accompanying tests for reference (BTW: I think the tests are referring to alt_validate instead of validate).

Alberto

comment:7 follow-up: ↓ 8 Changed 12 years ago by mramm

Ok, Ok! You win. ;)

I think you make some good arguments, expose will have to be on the outside, and inside decorators will be allowed to be real wrappers.

This should also allow us to port things like the paginate decorator over to TG2 much more easily.

But one of the things the people have trouble with is how decorators interact. So, this makes it important for us to document these decorators well, and to make sure we keep the interactions as clean as possible.

--Mark

comment:8 in reply to: ↑ 7 Changed 11 years ago by khorn

Replying to mramm:

But one of the things the people have trouble with is how decorators interact. So, this makes it important for us to document these decorators well, and to make sure we keep the interactions as clean as possible.

--Mark

Just an idea here, and I haven't really thought it through yet, but would it be possible (or advisable) to have the various decorators set some sort of flag in the decorated object, and have the decorators do some kind of magic to throw warnings when teh dev does something wrong?

I'm sure we couldn't catch every case (nor would we want to!), but something like this *MIGHT* be helpful for some users.

The question is, is it worth the extra effort, performance cost, etc. Wiser heads than mine can say for sure, just thought I'd throw it out there.

comment:9 Changed 11 years ago by mramm

  • Status changed from assigned to closed
  • Resolution set to fixed
  • Description modified (diff)

Closing this ticket and opening a new one to implement the new "Alberto style" validation decorator

comment:10 Changed 11 years ago by alberto

  • Status changed from closed to reopened
  • Resolution fixed deleted

I've committed in [3866] changes which improve TW integration. I've finally extended the new_validate decorator in Pylons to handle TW forms since the old "Alberto's Style" decorator I did in the first PyGears? sprint which I mention no longer works without heavy change, oh well... :)

Some notes:

  • Needs the attached validate.patch applied to Pylons (can we set up our Pylons hg repository?)
  • Attached a root.py and index.html templates which, I've dropped replacing the current files in a quickstarted app should demo the new functionallity.

Anyone could please try it out? Feedback appreciated.

Alberto

Changed 11 years ago by alberto

Changed 11 years ago by alberto

Changed 11 years ago by alberto

comment:11 Changed 11 years ago by mramm

  • Priority changed from normal to highest
  • Status changed from reopened to new
  • Owner changed from alberto to mramm

I need to get this stuff in Pylons prior to our sprint. I will try to get it tested and pushed up to Ben tonight.

comment:12 Changed 11 years ago by mramm

This is now verified to be in pylons.

comment:13 Changed 11 years ago by mramm

  • Status changed from new to closed
  • Resolution set to fixed

T

Changed 11 years ago by alberto

Note: See TracTickets for help on using tickets.