[
https://issues.apache.org/jira/browse/WW-5093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248557#comment-17248557
]
ASF GitHub Bot commented on WW-5093:
------------------------------------
yasserzamani commented on a change in pull request #154:
URL: https://github.com/apache/struts-site/pull/154#discussion_r541903584
##########
File path:
source/core-developers/accessing-application-session-request-objects.md
##########
@@ -50,16 +50,24 @@ is an alternative way to access the request and response
objects, with the same
## Accessing from the view (JSP, FreeMarker, etc.)
Request and session attributes are accessed via OGNL using the `#session` and
`#request` stack values.
+Page attributes are accessed via OGNL using the `#attr` stack value, and
Application attributes via
+the `#application` stack value.
The `#attr` stack value will search the `javax.servlet.jsp.PageContext` for
the specified key. If the `PageContext`
-doean't exist, it will search the request, session, and application scopes, in
that order.
+doesn't exist, it will search the request, session, and application scopes, in
that order.
-**Accessing the Session or Request from a JSP**
+**Accessing attributes in the Application, Session, Request, or Page scope
from a JSP**
```jsp
Review comment:
xml is better I think to highlight.
##########
File path:
source/core-developers/accessing-application-session-request-objects.md
##########
@@ -50,16 +50,24 @@ is an alternative way to access the request and response
objects, with the same
## Accessing from the view (JSP, FreeMarker, etc.)
Request and session attributes are accessed via OGNL using the `#session` and
`#request` stack values.
+Page attributes are accessed via OGNL using the `#attr` stack value, and
Application attributes via
+the `#application` stack value.
The `#attr` stack value will search the `javax.servlet.jsp.PageContext` for
the specified key. If the `PageContext`
-doean't exist, it will search the request, session, and application scopes, in
that order.
+doesn't exist, it will search the request, session, and application scopes, in
that order.
-**Accessing the Session or Request from a JSP**
+**Accessing attributes in the Application, Session, Request, or Page scope
from a JSP**
```jsp
+Retrieve the attribute (property), with key myId, from the specified scope:
Review comment:
Nice to use xml comment here i.e. `<!-- .... -->`
##########
File path: source/tag-developers/set-tag.md
##########
@@ -25,9 +25,10 @@ The scopes available are as follows:
- `session` - the value will be set in session scope according to servlet
spec. using the name as key
- `request` - the value will be set in request scope according to servlet
spec. using the name as key
- `page` - the value will be set in page scope according to servlet spec.
using the name as key
-- `action` - the value will be set in the request scope and Struts' action
context using the name as key
+- `action` - the value will be set in the page scope and Struts' action
context using the name as key
Review comment:
I think action would be request (thread) scope theoretically?
##########
File path:
source/core-developers/accessing-application-session-request-objects.md
##########
@@ -50,16 +50,24 @@ is an alternative way to access the request and response
objects, with the same
## Accessing from the view (JSP, FreeMarker, etc.)
Request and session attributes are accessed via OGNL using the `#session` and
`#request` stack values.
+Page attributes are accessed via OGNL using the `#attr` stack value, and
Application attributes via
+the `#application` stack value.
The `#attr` stack value will search the `javax.servlet.jsp.PageContext` for
the specified key. If the `PageContext`
-doean't exist, it will search the request, session, and application scopes, in
that order.
+doesn't exist, it will search the request, session, and application scopes, in
that order.
-**Accessing the Session or Request from a JSP**
+**Accessing attributes in the Application, Session, Request, or Page scope
from a JSP**
```jsp
+Retrieve the attribute (property), with key myId, from the specified scope:
+
+<s:property value="#application.myId" />
+
<s:property value="#session.myId" />
<s:property value="#request.myId" />
<s:property value="#attr.myId" />
+
+Reminder: attr is for Page scope attributes first, but will search the
remaining scopes, in order, seeking a match.
Review comment:
(same here)
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> inconsistent scope for variables created with s:set and s:url
> -------------------------------------------------------------
>
> Key: WW-5093
> URL: https://issues.apache.org/jira/browse/WW-5093
> Project: Struts 2
> Issue Type: Bug
> Components: Core Tags
> Affects Versions: 2.5.22
> Reporter: nikos dimitrakas
> Priority: Major
> Labels: scope, tag, var
> Fix For: 2.6
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The implementation of s:set and s:url and s:text is not consistent and not
> well documented.
> Creating a variable with s:set puts the variable in a different default scope
> than creating a variable with s:url or s:text (with the attribute var). It is
> also not documented what the default scope is. After testing I could conclude
> that the scope for a variable created by s:url is request, while the default
> of s:set is not. Furthermore, s:set offers a possibility to specify the scope
> with an attribute, But s:url and s:text do not.
> Possible options would be offering the possibility to specify the scope
> attribute in s:url and s:text, or dropping support for the var attribute for
> s:url and s:text and only allow s:set to create variables (thus being forced
> to nest s:url and s:text inside an s:set). That would be symmetric with how
> s:property does not offer the var attribute. At minimum all three tags should
> have the same default and their default should be explicitly specified in the
> documentation (in the tld and the online manual / tag reference)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
