It's the xdocs, they're under framework/src/documentation/content/xdocs/tapestry .
On 3/10/06, Fernando Padilla <[EMAIL PROTECTED]> wrote: > > Thank you. What do I have to change to update the docs; I'll try figure > it out? I just updated the component parameter descriptions. > > Jesse Kuhnert (JIRA) wrote: > > [ http://issues.apache.org/jira/browse/TAPESTRY-880?page=all ] > > > > Jesse Kuhnert resolved TAPESTRY-880: > > ------------------------------------ > > > > Fix Version: 4.0.1 > > Resolution: Fixed > > > > Fixed, thank you. Docs? > > > > > >>need 'port' parameter to supplement 'scheme' parameter for correct > generation of urls > > >>------------------------------------------------------------------------------------- > >> > >> Key: TAPESTRY-880 > >> URL: http://issues.apache.org/jira/browse/TAPESTRY-880 > >> Project: Tapestry > >> Type: Bug > >> Components: Framework > >> Versions: 4.1, 4.0.2, 4.0.1, 4.0 > >> Reporter: Fernando > >> Assignee: Jesse Kuhnert > >> Fix For: 4.0.1 > >> Attachments: schemeportsupport.patch > >> > >>There are lots of components ( Form, LinkComponent, etc ), which allow > you to change the destination scheme, but I don't think that is > enough. Issue TAPESTRY-786 tried to bring this to light, but wasn't clear, > and marked resolved incorrectly. > >>The issue is that if I were to change a url from HTTP to HTTPS, then I > have to change the SCHEME AND PORT. > >>HTTP/80 --> HTTPS/443 > >>or more apt during development: > >>HTTP/8080 --> HTTPS/8443 > >>I can't simply change the scheme: > >>HTTP/80 --> HTTPS/80 > >>HTTP/8080 --> HTTPS/8080 > >>because I do not ( and I don't think I can even set this up ), a > webserver listenting for both HTTP and HTTPS traffic on the same port. > >>Also there is no way for the system to just KNOW what the destination > port will be. We could have some heuristics, like if HTTP/80 --> HTTPS > assume 443, or HTTP/8080 --> HTTPS assume 8443, but what of all the other > random ports that we setup for testing and various reasons... > >>** I think we at least need to expose the destination port as a > parameter as we now expose the scheme. ** So I will submit my patch that > will do this. At the moment it is against tapestry/trunk, but I think this > should be back ported to encourage it's earlier release. > >>( We could even roll in the ability to change the destination HOST, or > even the destination CONTEXTROOT, but those would be enhancements rather > than required fixes. And we could be opening up a pandoras box. ) > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
