{5} Assigned, Active Tickets by Owner (Full Description) (5 matches)
List tickets assigned, group by ticket owner. This report demonstrates the use of full-row display.
argh@… (2 matches)
| Ticket | Summary | Component | Milestone | Type | Severity | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #71 | GetFromUrl: extract only part of the page | Components | defect | normal | 09/04/04 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
It would be good, if you could specify whether only the body of the page should be fetched. Furthemore specifying a regexp might be a nice feature. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #119 | More flexible NavFromSitemap component | Components | enhancement | normal | 04/04/05 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Playing around with patPortal to use it for a simple page layout, I've found NavFromSitemap? a bit inflexible and done a ExtNavFromSitemap? component. Differences are:
This way, I can use the same component for displaying a (e.g.) horizontal menu that only shows the topmost level of the sitemap hierarchie and a vertical menu that shows a second level portion of the sitemap. class patPortal_Component_ExtNavFromSitemap extends patPortal_Component {
$response )
: 'NavFromSitemap?');
: 'NavFromSitemap?');
$this->paramsbubbleActive? : false);
'visibility', 'visible' );
'visibility', 'hidden' );
} Because the parameter $path gets set via config, this makes the subtree shown independend from the current top level path. This might apply to some situations while far more typically we'd have the "second level" subtree depending on the current top level path.
with a
we'd get only the topmost nodes
with a
the component would _always_ show the subtree
It would make sense to invent another parameter $level or so to have the subtree selected sensitively by the current top level path: public function render(...) {
} Sorry, I haven't had the time to test this. I think, with a
that should load the subtree of the current top level path. For path=projects or path=project[n], we'd get
For path=presentations or path=presentations.presentation[n], we'd get
And for path=aboutus the component would show up nothing. PS: please correct assignments like prio, serverity etc. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
schst@… (3 matches) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Ticket | Summary | Component | Milestone | Type | Severity | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #117 | Need error handling | Framework | v0.5.0 | defect | normal | 03/31/05 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
There is no doubt that patPortal is still under heavy devolpement. But since there are several patPortal installations it is necessary to implement a basic error handling. Thx in advance Bjoern |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #120 | Remove SessionID from URL | Framework | enhancement | normal | 04/04/05 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
How can I remove the SessionID from my URLs? I.e., how can I have sessions that don't rely on URL rewriting but on cookies? PS: please correct assignments like prio, serverity etc. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #121 | Make Page_Forward work with relative URIs | Framework | v0.5.0 | enhancement | normal | 04/04/05 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
How to redirect to a relative uri? Don't know if this is the way I'm meant to go, but I tried to integrate a Wordpress blog into a site by adding a Page_Forward to the sitemap. Something like:
Looking at Response_Http::forwardTo(), it's not possible to use a relative uri by doing something like
As far as I understand the design, forwardTo() would need the request as an additional parameter to be able to look at the request's base uri and prepend it to a relative forward uri. So I tried to change the interface's protocol to:
But then I noticed that there's no method available in $request to determine the raw "base uri" (as I understand it), i.e. an uri like http://domain.ltd/myproject/ Instead, Request_Http::getBaseUri() returns the complete dispatcher uri like http://domain.ltd/myproject/index.php Don't know if it's appropriate to change the Request's api. I'd find it more intuitive to have something like:
and in Response_HTTP::replaceUrls() replacement of tokens
With:
forwarding to relative urls could be done by:
or alternatively by:
For now - without screwing up any api/bc, a simple solution could be to just modify Response_Http::forwardTo() like follows:
dirname($_SERVERPHP_SELF?) . '/' . $uri;
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
