Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

annotation documentation expression language #105

Closed
dbu opened this issue Jul 15, 2014 · 10 comments
Closed

annotation documentation expression language #105

dbu opened this issue Jul 15, 2014 · 10 comments
Assignees
Milestone

Comments

@dbu
Copy link
Contributor

dbu commented Jul 15, 2014

i fear that the expression language example in the annotation doc are wrong. the TagSubscriber only passes in request and response, but not the parameters to the method that was called. if we can manage to provide the named parameters, that would be awesome. otherwise we should change the examples to use the request object.

i also got the impression that * @Tag(expression="'news-'~article.id") mentioned in
http://foshttpcachebundle.readthedocs.org/en/latest/tagging.html#invalidate-tags will not work. for me, expression language did not behave like twig, i had to write article.getId().

@dbu dbu added bug labels Jul 15, 2014
@stof
Copy link
Member

stof commented Jul 15, 2014

for the second part, this is true. article.id will only go through the public property, not through several ways to access it (this is needed to be able to provide a compiled expression)

@ddeboer ddeboer added this to the 1.0 milestone Jul 18, 2014
@ddeboer
Copy link
Member

ddeboer commented Jul 19, 2014

Would it be enough if we pass $request->attributes alongside with $request and $response to the evaluator?

@dbu
Copy link
Contributor Author

dbu commented Jul 20, 2014

ah, probably yes. though you would need to merge the attributes with request and response, to not pass a nested array. it all happens after routing so the values will be available.

or we say to use request.attributes... to access request attributes.

@ddeboer
Copy link
Member

ddeboer commented Jul 20, 2014

What convention does Symfony follow here? Is there any place they combine ParamConverter with ExpressionLanguage?

@dbu
Copy link
Contributor Author

dbu commented Jul 20, 2014

no idea. but i think getting a copy of the attributes array and adding request and response sounds ok to me.

@ddeboer ddeboer self-assigned this Jul 30, 2014
@dbu
Copy link
Contributor Author

dbu commented Jul 30, 2014

shall we remove this feature for now, or do you have time to fix it?

@ddeboer
Copy link
Member

ddeboer commented Jul 30, 2014

I’m fixing it as we speak.

@ddeboer
Copy link
Member

ddeboer commented Jul 30, 2014

At least here and there the convention is to evaluate against $request->attributes->all(), so I’ll just follow that.

@ddeboer
Copy link
Member

ddeboer commented Jul 30, 2014

Wait, we’re already doing this for the Tag annotation. @dbu So can we close this? Or should something be changed here too?

@dbu
Copy link
Contributor Author

dbu commented Jul 30, 2014

hm, i think it does not hurt to also support them in the configured tagging too, not only in annotations. chances are a configuration matches several requests, but that is up to the user to think about what he is doing.

i see the documentation is already fixed.

ddeboer added a commit that referenced this issue Jul 30, 2014
* configured tags can access request.attributes with simple expression vars (id)
* response is no longer available as a value for expressions; but there’s no use case
  for that anyway
* update docs
dbu added a commit that referenced this issue Jul 31, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants