DO NOT REPLY [Bug 26695] - [struts-chain] Modules don't get handled correctly.

2004-02-29 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26695.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26695

[struts-chain] Modules don't get handled correctly.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-02-29 13:24 ---
As noted previously, the fact that this showed up in a module deployment was probably 
a coincidence; 
instead, the Chain AbstractSelectForward class was just incorrectly paying attention 
to the value of 
controllerConfig.getInputForward, which I believe only applies in AbstractSelectInput.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts Change Tracking (Re: [ANNOUNCE] Struts 1.2.0 Test Build available)

2004-02-29 Thread Ted Husted 
Right now, I'm using the Maven changelog as a cut-and-paste guide to the release 
notes.  I think the change plugin could be a replacement for this, especially if we 
start release more than one product, each of which could have their own change file. 
(struts-core, struts-opt-taglibs, struts-opt-el, struts-opt-apps, and so forth.)

I do agree that that we need to summarize the changelog to turn data into information, 
and the changes plugin might be a help with that.

Though, since part of that is categorizing the changes, I think we need to divy up 
the distribution before changing what we now do for release note changes.

Personally, I'd like to prioritize moving the build over to Maven, and dividing the 
distribution into multiple artifacts with their own release cycles, so that we start 
taking advantage of features like this.

-Ted.

On Fri, 27 Feb 2004 08:10:53 -0600, Joe Germuska wrote:
 At 9:05 AM +0100 2/27/04, nicolas De Loof wrote:
 Can you please post a what's new about this release to help me
 make my boss agree to use Struts 1.2.0 for new projects ?


 Are committers familiar with the Maven changes.xml file/plugin?  If
 it exists, it can be used to generate something that looks like
 this:

 http://maven.apache.org/changes-report.html


 Even though Maven isn't our primary build mechanism, using
 changes.xml might be a good way to track what we're doing.  I hope
 I'm not embarassing myself, but there isn't any basic change log
 already is there?  If so, I sure haven't been tracking it.

 I guess putting every single commit into the changes.xml file isn't
 appropriate, or the thing would get huge.  Also, Maven can generate
 a separate report for that (http://maven.apache.org/changelog-
 report.html)

 Since changes.xml is structured, we could probably come up with a
 transform to use it in the current Ant-built documentation until we
 are using Maven, and if nothing else, it provides a single place to
 log things.
 Of course, if people don't think it's worth the energy, I'd rather
 leave it out than have it there but inaccurate.

 Joe


 PS an example of the XML syntax is here:
 http://maven.apache.org/reference/plugins/changes/  It's about as
 much doc as I've ever seen for it.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 26675] - [struts-chain] uploads greater than memory threshold don't get written to disk

2004-02-29 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26675.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26675

[struts-chain] uploads greater than memory threshold don't get written to disk

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-02-29 13:54 ---
This is fixed; there was a logic error which was rolling back the multipart request 
when there were no 
errors, which caused the disk-based files to be cleared.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 27321] - Automatic invalid format handling for form bean

2004-02-29 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27321.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27321

Automatic invalid format handling for form bean





--- Additional Comments From [EMAIL PROTECTED]  2004-02-29 13:57 ---
I think the underlying problem is that we still lack a slick package that can 
handle data validation, tranformation, and conversion from a single 
configuration. Instead of trying to wire arbitrary JavaBeans up to an 
ActionForm, we should be able to populate a typed JavaBean from a package that 
takes a Map of Strings as input

AND: 

return a Map of FORMATTED strings from a typed JavaBean. Bidirectional 
conversions and transformations being essential for roundtripping input to the 
persistence layer and back again. By transformation I mean taking a String 
like 1234567890 and rendering it as (123) 456-7890, or taking a Date or 
Double and rendering the data in whatever style.

One package that comes quite close in this regard is FormProc at SourceForge 
(formproc.sf.net). It's underdocumented, and we need to make the conversions 
bidirectional, but, IMHO, it's moving in the right direction.

The essential idea is that same configuration that tells us incoming dates (or 
whatever) are formatted in a certain way would also tell us that outgoing 
entries are formatted the same way. Ditto for currencies, and telephone 
numbers, and so forth. 

Given such a beast, we could then populate and debrief business objects with 
one simple call. We could even allow an arbitrary object to be (optionally) 
associated with an ActionMapping and autopopulated if validate passes. This 
would not change the nature of ActionForms in anyway, or require any 
additional configurations information over what is already provided, but 
simply leverage what we already know, to do what most everyone needs to do. 

But what's still needed is the ability to execute bidirectional 
conversions/transformations with the Validator, or something like it, then the 
rest falls into place. 

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 26639] - Multipart request parameters lost after validation failure

2004-02-29 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26639.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26639

Multipart request parameters lost after validation failure





--- Additional Comments From [EMAIL PROTECTED]  2004-02-29 14:00 ---
Turns out that this is not directly related to 26675, which was a simple bug in the 
conversion of the 
RequestProcessor functionality into chain commands which hadn't been put to the test.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 27321] - Automatic invalid format handling for form bean

2004-02-29 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27321.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27321

Automatic invalid format handling for form bean





--- Additional Comments From [EMAIL PROTECTED]  2004-02-29 14:13 ---
I was under the impression this is what JSF was supposed to do.

Edgar

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: 1.2.x and beyond (was Tagging and Freezing)

2004-02-29 Thread Niall Pemberton 
Ted,

Whats happening with your Jericho proposal - I looked in the cvs/contrib and
just saw the overview - is there anything more concrete anywhere else and
are you still looking at pursuing this 'struts revolution'?

Niall

- Original Message - 
From: Ted Husted [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Sunday, February 29, 2004 2:12 PM
Subject: Re: 1.2.x and beyond (was Tagging and Freezing)


On Fri, 27 Feb 2004 23:27:35 -0800, Craig R. McClanahan wrote:
 * Create a CVS branch for this release, which starts as a snapshot
  of the development tree when the release candidate is initially
 created, and allows the RM to incorporate whatever subsequent HEAD
  branch commits make sense (by either doing a CVS join or manually
  interpoLating the fixes).

I'd be in favor of creating a branch for 1.2.x, so that we could finishing
mavenising the HEAD, and be able to fixes to 1.2.x in the meantime.

I believe that, as a result of the Maven initiative, we will also have
multiple products/artifacts to distribute (struts-core, struts-opt-taglib,
et cetera). If so, we could start each of these out at version 1.3.0, and
then proceed from there with more aggressive enhancements (like
Struts-Chain).

So, the 1.2.x series (out there) is mainly about removing deprecations and
refactoring existing features (like modules).

Release 1.3.0 could be about repackaging the build for Maven and also doing
the release subdividing that we've been talking about for some time now.

Releases 1.3.1+ could then get back to the business of creating Struts
[rather than just maintaining it] :)

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Bug report for Struts [2004/02/29]

2004-02-29 Thread bugzilla 
+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| |   |   MIN=Minor   NOR=Normal  ENH=Enhancement   |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|  866|New|Enh|2001-03-06|Clean Way to Add Parameters to Redirecting Forward|
| 3202|Opn|Enh|2001-08-21|OptionsTag.doEndTag - calls method to populate se|
| 5395|Opn|Enh|2001-12-12|ActionContext class   |
| 5566|New|Enh|2001-12-21|html:link bug |
| 5739|Opn|Enh|2002-01-08|Struts fails silently in too many places  |
| 5937|New|Enh|2002-01-21|html:form trims all extensions|
| 6686|New|Enh|2002-02-26|make action attribute of html:form tag optional |
| 6847|Opn|Enh|2002-03-04|Multiple file upload not possible due to MultiPart|
| 7892|Opn|Enh|2002-04-09|Using Multiple Resource Bundles for an Application|
| 7902|Opn|Enh|2002-04-10|The exception handling declaration in the DTD does|
| 9088|Opn|Enh|2002-05-15|FormTag.getActionMappingURL() assumes 1 servlet ma|
| 9616|New|Enh|2002-06-05|Some more Struts docs |
| 9748|New|Enh|2002-06-10|attribute labelKeyProperty for Options tag|
|10550|New|Enh|2002-07-08|Delegate path-management to ActionForwards|
|10551|Opn|Enh|2002-07-08|Allow a struts-config element to extend another   |
|10552|New|Enh|2002-07-08|create helper objects in struts-config|
|10867|Opn|Enh|2002-07-16|Add indexedProperty attribute in html taglibs |
|11154|Opn|Enh|2002-07-25|html:link tag extension for multiple parameters   |
|11733|Opn|Enh|2002-08-15|Make error keys more specific |
|12170|Opn|Enh|2002-08-29|Added functionality when extending another definit|
|12301|Opn|Enh|2002-09-04|nested:messages Tag does not work as expected |
|12313|Opn|Enh|2002-09-04|Chaining of RequestProcessors--contribution   |
|12342|Ass|Enh|2002-09-05|Add default exception handler attribute to global|
|12600|New|Enh|2002-09-12|html:form tag always prepends context path to acti|
|13125|Opn|Enh|2002-09-30|Lack of character-set while using  html:html  ta|
|13521|New|Enh|2002-10-11|CombinedDispatchAction|
|13544|Opn|Enh|2002-10-11|[exception] support contextRelative paths |
|13565|Opn|Enh|2002-10-12|To errors, add prefix, suffix, header, footer at|
|13638|Opn|Enh|2002-10-15|add Config Factory|
|14068|Opn|Enh|2002-10-29|Why can't I use forwards with exception elements i|
|14071|Opn|Enh|2002-10-29|Need clear info on which Struts attributes produce|
|14183|New|Enh|2002-11-01|html:img does not support forward attribute   |
|14749|Opn|Enh|2002-11-21|Action input not starting with '/' and not a val|
|15023|Opn|Enh|2002-12-03|Use attribute 'id' instead of 'name' in html:form-|
|15188|Opn|Enh|2002-12-09|roles attribute of tags and definitions only allow|
|15422|Opn|Enh|2002-12-17|Form Tag exportFormName  attribute|
|15604|Opn|Enh|2002-12-22|Struts framework should use getInstance Method for|
|15670|Opn|Enh|2002-12-26|Doc for exception element needs to mention page|
|15673|Opn|Enh|2002-12-26|Default Action in ActionMapping   |
|15805|Opn|Enh|2003-01-05|Enhance ModuleException to allow getting chained E|
|15816|Opn|Enh|2003-01-06|html:form focus in pages with several forms   |
|15849|Opn|Enh|2003-01-07|Incorrect documentation for Developing Your Own M|
|15912|Opn|Enh|2003-01-09|Client-side validation fails if not all form-field|
|15921|Opn|Enh|2003-01-09|Allow relative actions in struts-config.xml   |
|15935|Opn|Enh|2003-01-09|WSAD 5.0 Instructions for Struts Example  |
|15969|Opn|Enh|2003-01-10|Ability to use TilesRequestProcessor even if it no|
|16074|New|Enh|2003-01-14|html:form uses 'action' not 'input' to select mapp|
|16104|Opn|Enh|2003-01-15|default handler parameter value for LookupDispatch|
|16107|Opn|Enh|2003-01-15|Configure if you want to call ActionForm.reset() i|
|16207|Opn|Enh|2003-01-17|Add ability to import tile attributes into a java.|
|16249|Opn|Enh|2003-01-20|localized float validation|

Re: 1.2.x and beyond (was Tagging and Freezing)

2004-02-29 Thread Ted Husted 
I had been putting all my Struts hours into 1.2.0, but now that we're past that, I can 
take a look at this again.

To an extent, I believe it not only represents a 2.x product we might want to build, 
but also a direction in which we might want to steer 1.x.

-Ted.


On Sun, 29 Feb 2004 15:14:20 +, Niall Pemberton wrote:
 Ted,


 Whats happening with your Jericho proposal - I looked in the
 cvs/contrib and just saw the overview - is there anything more
 concrete anywhere else and are you still looking at pursuing this
 'struts revolution'?

 Niall


 - Original Message -
 From: Ted Husted [EMAIL PROTECTED]
 To: Struts Developers List [EMAIL PROTECTED] Sent:
 Sunday, February 29, 2004 2:12 PM
 Subject: Re: 1.2.x and beyond (was Tagging and Freezing)


 On Fri, 27 Feb 2004 23:27:35 -0800, Craig R. McClanahan wrote:

 * Create a CVS branch for this release, which starts as a
 snapshot of the development tree when the release candidate is
 initially created, and allows the RM to incorporate whatever
 subsequent HEAD branch commits make sense (by either doing a CVS
 join or manually interpoLating the fixes).


 I'd be in favor of creating a branch for 1.2.x, so that we could
 finishing mavenising the HEAD, and be able to fixes to 1.2.x in
 the meantime.

 I believe that, as a result of the Maven initiative, we will also
 have multiple products/artifacts to distribute (struts-core, struts-
 opt-taglib, et cetera). If so, we could start each of these out at
 version 1.3.0, and then proceed from there with more aggressive
 enhancements (like Struts-Chain).

 So, the 1.2.x series (out there) is mainly about removing
 deprecations and refactoring existing features (like modules).

 Release 1.3.0 could be about repackaging the build for Maven and
 also doing the release subdividing that we've been talking about
 for some time now.

 Releases 1.3.1+ could then get back to the business of creating
 Struts [rather than just maintaining it] :)

 -Ted.


 
 - To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 - To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 27321] - Automatic invalid format handling for form bean

2004-02-29 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27321.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27321

Automatic invalid format handling for form bean





--- Additional Comments From [EMAIL PROTECTED]  2004-02-29 22:11 ---
I had worked on and had been using a Struts plugin which does a lot of what Ted 
had mentioned.  It supports bidirectional conversions and transformation, 
handles formatting and parsing to and from typed and String data, can combine 
form definition and validation configuration, and even reduce the needed config 
info needed.  It's built specifically for Struts and does not change the nature 
of ActionForms -- in fact it requires it.  Adding it to an existing Struts app 
will not affect existing ActionForms and/or Validator config except when moved 
over to take advantage of the plugin.
I am more than willing to contribute it (that's the original goal anyway) 
either as a starting point for any such enhancement or even, if disliked by the 
community, just an example of what not to do.  If so, I'd be willing to help in 
creating a new version the community will accept.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-struts/xdocs/faqs helping.xml kickstart.xml

2004-02-29 Thread martinc 
martinc 2004/02/29 14:55:46

  Modified:.build.xml project.xml
   conf/share MANIFEST.MF
   contrib  project.xml
   contrib/artimus/WEB-INF build.xml
   contrib/scaffold/conf/framework manifest
   contrib/scaffold/conf/sample manifest
   contrib/struts-chain/src/conf MANIFEST.MF
   contrib/struts-el build.xml
   contrib/struts-el/doc/stylesheets proposals.xsl struts.xsl
userGuide.xsl
   contrib/struts-faces build.xml
   contrib/struts-faces/src/conf MANIFEST.MF struts-doc.xsl
   contrib/struts-faces/src/example2/org/apache/struts/webapp/example2
ApplicationResources.properties
   doc  index.xml
   doc/faqs helping.xml kickstart.xml
   doc/stylesheets struts.xsl
   web/tiles-documentation/common footer.jsp
   web/tiles-documentation/examples/tiles footer.jsp
   xdocsfaq.fml
   xdocs/faqs helping.xml kickstart.xml
  Log:
  Correct the ASF name, per Greg Stein's note.
  
  Revision  ChangesPath
  1.130 +1 -1  jakarta-struts/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-struts/build.xml,v
  retrieving revision 1.129
  retrieving revision 1.130
  diff -u -r1.129 -r1.130
  --- build.xml 27 Feb 2004 06:26:42 -  1.129
  +++ build.xml 29 Feb 2004 22:55:45 -  1.130
  @@ -353,7 +353,7 @@
   version=true
   windowtitle=Apache Struts API Documentation
   doctitle=lt;h1gt;Apache Struts Framework (Version 
${project.version})lt;/h1gt;
  -bottom=Copyright #169; 2000-${year} - Apache Software Foundation
  +bottom=Copyright #169; 2000-${year} - The Apache Software Foundation
   classpath refid=compile.classpath/
   /javadoc
   /target
  
  
  
  1.25  +1 -1  jakarta-struts/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-struts/project.xml,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- project.xml   27 Feb 2004 14:27:04 -  1.24
  +++ project.xml   29 Feb 2004 22:55:45 -  1.25
  @@ -5,7 +5,7 @@
 idstruts/id
 currentVersion1.2.1-dev/currentVersion
 organization
  -nameApache Software Foundation/name
  +nameThe Apache Software Foundation/name
   urlhttp://jakarta.apache.org//url
   logohttp://jakarta.apache.org/images/jakarta-logo.gif/logo
 /organization
  
  
  
  1.10  +2 -2  jakarta-struts/conf/share/MANIFEST.MF
  
  Index: MANIFEST.MF
  ===
  RCS file: /home/cvs/jakarta-struts/conf/share/MANIFEST.MF,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- MANIFEST.MF   29 Jan 2004 19:06:16 -  1.9
  +++ MANIFEST.MF   29 Feb 2004 22:55:45 -  1.10
  @@ -1,10 +1,10 @@
   Manifest-Version: 1.0
   Extension-Name: Struts Framework
   Specification-Title: Struts Framework
  -Specification-Vendor: Apache Software Foundation
  +Specification-Vendor: The Apache Software Foundation
   Specification-Version: 1.2.0
   Implementation-Title: Struts Framework
  -Implementation-Vendor: Apache Software Foundation
  +Implementation-Vendor: The Apache Software Foundation
   Implementation-Vendor-Id: org.apache
   Implementation-Version: 1.2.0
   Class-Path: 
  
  
  
  1.4   +1 -1  jakarta-struts/contrib/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-struts/contrib/project.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- project.xml   10 Jan 2004 23:43:51 -  1.3
  +++ project.xml   29 Feb 2004 22:55:45 -  1.4
  @@ -7,7 +7,7 @@
 currentVersion1.0/currentVersion
   
 organization
  -nameApache Software Foundation/name
  +nameThe Apache Software Foundation/name
   urlhttp://www.apache.org/url
   inceptionYear2000/inceptionYear
 logohttp://jakarta.apache.org/images/jakarta-logo.gif/logo
  
  
  
  1.4   +2 -2  jakarta-struts/contrib/artimus/WEB-INF/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-struts/contrib/artimus/WEB-INF/build.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- build.xml 18 Jan 2004 13:43:07 -  1.3
  +++ build.xml 29 Feb 2004 22:55:45 -  1.4
  @@ -67,7 +67,7 @@
   version=true
   windowtitle=Artimus API Documentation
   doctitle=lt;h1gt;${project.title} Documentation (Version