1 May
2005
1 May
'05
9:24 a.m.
Hi,
this is an interesting problem Philippe and I have been discussing
yesterday: he wanted that a certain component rendered html anchor
tags to all the links in order to let the web browser jump to the
right position in the page. I think this is a nice design discussion:
he suggested a first solution, that I tried to improve, but that
didn't solve the problem yet ... sorry, partly in german ...
You would set it from the parent component if desired, or even better
let the renderer ask its component for the anchor-id to be used.
Wäre es nicht
einfach eine
Subklasse von MAReport zu machen und dort #rendererClass zu
überschreiben, das einen Subklasse von WAHtmlRenderer zurückgibt,
welche die Methode #anchorWithUrl:do: überschreibt und dort die
entsprechenden ids ganz hinzufügt?
Daran hatte ich gar nicht gedacht. Wir hatten zuerst eine
Subklasse, ich
habs aber dann in MAReport gepusht um es dir zu schicken. Zudem
haben wir ja
auch MAColum abgeändert. Was meiner Meinung nach noch hässlicher
ist. Aber
das liesse sich ja auch elegant mit dem renderer lösen.
Ich habe jetzt noch zwei Fragen:
Wie komme ich im renderer an die ids? Im Moment sind die ja im
Report und
die müssten ja über mehrere rendering Vorgänge stabil bleiben. Wie ist das mit Links, die sich nicht auf den Report
beziehen. Z.B.
actions
(edit, remove) die ev. in einer ganz neuen Seite resultieren würden
(z.B
wegen #call:). Dort würde ich ja auch überall den anchor hinzufügen
obwohl
es in der Zielseite ev. gar nicht existiert. Hast du eine Idee wie
ich das
verhindern kann?
Okay, what about this idea? Use a customized renderer that uses a
dynamic variable (subclass of WADynamicVariable) to determine what
anchor has to be appended and that will not change anything if this
value is nil.
BlaBla>>renderContentOn: html
SW2DynamicAnchorTarget
use: 'theSuperAnchor'
while: [ html render: self report ].
SW2HtmlRenderer>>anchorWithUrl: aUrl do: aString
SW2DynamicAnchorTarget value in: [ :value |
uper
anchorWithUrl: (value isNil
ifTrue: [ aUrl ]
ifFalse: [ aUrl , '#' , value ])
do: aString.
I think like this you can do anything you need to do? If you can iron
out this concept (maybe using the new Seaside brush rendering
framework) this would be something that should go into Seaside
itself, I suspect.
Moreover, I think this is an excellent example how the design of your
code can be improved by discussing and rethinking a problem several
times. In fact, the above code avoids the need to change 30 methods
in a non generic fashion and even allows it to be reused in different
contexts.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
1 May
1 May
11:45 a.m.
New subject: MAReport
On 5/1/05, Lukas Renggli <renggli(a)iam.unibe.ch> wrote:
Okay, what about this idea? Use a customized renderer
that uses a
dynamic variable (subclass of WADynamicVariable) to determine what
anchor has to be appended and that will not change anything if this
value is nil.
Hi Lukas,
Why not add just an instance variable to the rendering context?
Another interesting approach here that I recently discovered is to set
the anchor name after the page is already loaded using Javascript:
<script>document.location.hash = "anchorname"</script>
This would let us have a render method that was simply something like
#jumpToHere that would generate a new unique named anchor and the
script to force the browser to it.
However, it may be awkward to know at render time what part of the
page to jump to (it usually depends more on what the most recent user
action was than on the current static state, so you have to find some
way to carry that information over from the callback phase).
Anyway, this is certainly an interesting general problem and I'd like
to see a good standard solution for it in Seaside.
Avi
12:24 p.m.
New subject: MAReport
Hi Avi,
I was just about to forward this mail to you, I didn't know that you
are on the list as well ;-)
Why not add just an instance variable to the rendering
context?
Okay, this works for a generic page, however it doesn't work when you
have nested components. But still, the dynamic variable doesn't solve
the problem when it isn't implemented in the most generic renderer,
since the children might use another one.
Another interesting approach here that I recently
discovered is to
set the anchor name after the page is already loaded using Javascript:
<script>document.location.hash = "anchorname"</script>
Yeah, this sounds like an even simpler idea. Would it solve your
problems, Philippe?
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
3:53 p.m.
New subject: MAReport
Hi
Well first it's JavaScript based. If I can use JavaScript, then I can use
LiveUpdate was well and just replace/refresh the component.
Second, this should happen only once and only for the component that
rendered the link that was clicked. So for example if you have a page with
three reports, you sort the second, then this script should only be
generated for the anchor of the second report.
Cheers
Philippe
--
+++ GMX - die erste Adresse f�r Mail, Message, More +++
10 GB Mailbox, 100 FreeSMS http://www.gmx.net/de/go/topmail
Another
interesting approach here that I recently discovered is to
set the anchor name after the page is already loaded using Javascript:
<script>document.location.hash = "anchorname"</script>
Yeah, this sounds like an even simpler idea. Would it solve your
problems, Philippe?
4:12 p.m.
New subject: MAReport
On 5/1/05, kustos(a)gmx.net <kustos(a)gmx.net> wrote:
Well first it's JavaScript based. If I can use
JavaScript, then I can use
LiveUpdate was well and just replace/refresh the component.
That doesn't follow; using LiveUpdate (I suppose we should be hip and
call it AJAX now) has lots of other side effects (the back button
behavior would change, for example), and it takes some effort to make
it degrade nicely. Using a script to set the fragment/hash section of
the URL is much simpler, and degrades just fine (the page won't jump
to the right point but that's it).
Second, this should happen only once and only for the
component that
rendered the link that was clicked. So for example if you have a page with
three reports, you sort the second, then this script should only be
generated for the anchor of the second report.
Certainly. As I said, the difficulty is knowing at render time where
to insert the script. This is very similar to the original problem of
knowing which fragment to append to a URL; all the script does is let
you make the choice after the callback has happened rather than
before. That may not turn out to be that useful.
Avi
6957
days inactive
6957
days old
4 comments
3 participants
participants (3)
-
Avi Bryant -
kustos＠gmx.net -
Lukas Renggli