> Patrick Heiden pisze:
> >
> > I think the basic idea is simple and elegant - so all one needs to do is
> configure mod-cache to
> > handle expires properly (what should be easy for statics like e.g. imgs,
> hopefully ;) and then
> > use servlet:/somegif.gif inside HTML. Would really enjoy to try this
> out, but need further
> > information about howto actually enable access via servlet:/ inside
> HTML. Maybe assume I am using
> > JXTemplates or some other view-tech wich contain some cachable statics.
> From my (shorttime
> > cocoon) experience this would then work fine (even if one calls statics
> inside e.g. css inside
> > conventional resource/ directory).
>
> The trick with servlet: protocol inside HTML is that before serializing it
> to the browser (or httpd)
> it must be /rewritten/. Obviously, both httpd and browser have no idea
> what 'servlet:' protocol
> thing is so just before serializing the HTML you need to add
> servletLinkRewriter transformer. Your
> pipeline should look like:
> <map:generate src="some_jx_template_for_html.jx" type="jx"/>
>
> [some transformation steps here]
>
> <map:transform type="servletLinkRewriter"/>
> <map:serialize type="html"/>
>
> The magic performed by servletLinkRewriter (coming from
> cocoon-servlet-service-components) is not
> that mysterious. Basically, it scans for href and src attributes
> containing servlet: protocol URLs.
> Then it uses some machinery from SSF in order to translate servlet:/**
> path into path that browser
> can understand.
>
> Suppose everything happens in a servlet named 'foo' and mounted at
> /foo_mount/. If
> servletLinkRewriter encounters URL like servlet:/external/logo.gif it
> translates it into
> /foo_mount/external/logo.gif that browser can obviously handle.
>
> This way, if browser asks for /blocks_mount_path/external/logo.gif it's
> being dispatched by SSF to
> foo servlet that will see it as a request for /external/logo.gif resource
> which is exactly that
> servlet:/external/logo.gif means here!
>
> It's worth to note that servletLinkRewriter supports polymorphism and
> there is servletLinkRewriter
> *reader* that can deal with e.g. CSS files and links inside them.
Very cool stuff! New add to my component list.
Finished reading the wikis. Think that main work lays in configuring the actual
expires due to the fact that entire static sites would not lay inside
cocoon-apps anyway [ ;) ]- so we want to cache static stuff like this:
Assume we have webApp wich has a mainController-block [bA] for
high-level-routings:
- request comes in and is routed by mainController
+- basic aggregates inside bA's sitemap, e.g. for layout an navigation
+- static stuff (imgs, js,...) rest inside bA's resource/external
+- additional aggregates (using SSF) e.g. connect to domainmodel
+- connected blocks could also have statics inside resource/external
+- and so on
all statics should be cached, right? This approach would then solve issues for
caching all imgs and js, since 'user-hided' calls from browser/proxy to cocoon
wich resolve the imgs an js and the like (even css if wanted and added
properly) are not proxied (wich means served directly). But why tie this
caching to expires, since these are in whole page-scope, aren't they?
>
> > Besides: do you have additional information about cocoon-auth block for
> usage in production. I am
> > trying to enable users to log in from another host and then they should
> automatically routed to
> > their last view. Ideally the left host should be pointed to login again.
>
> Unfortunately not.
Well..think I will find something. Looking at the block-examples just leaves
one with basic auth-stuff, not using session-data like IPs. In case of a
relogin, maybe a check of users IP (out of session) combined with automated
logging off and serving the last view would work. Will try this first. Are
there any common pitfalls with sessions and continuations (wich should then be
configured in session-scope)?
> Great. As I said, it would be nice if you could share your experiences
> (possibly by writing some
> tutorials).
Of course I will do so and I would like to start with little tut about
block-design in the so often mentioned mainController-manner as soon as I
finished this task. But performance boosting is on the list, too ;)
Best greetings,
Patrick
>
> --
> Best regards,
> Grzegorz Kossakowski
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
