Aparajita,
thank you very much. You answer is very helpful.
>>
>
> It's up to you. You are certainly free to put the sidebar output into a
> variable (I would actually suggest putting it in the _request collection) and
> then showing that in the sidebar with a simple 'write raw' command. You'll
> want to use 'write raw' if the output has already been created by 'write'
> commands. So it would be something like this:
>
> save output(_request{"sidebar"})
> write("foo")
> write("bar")
> // etc.
> end save output
>
> // in sidebar
> write raw(_request{"sidebar"})
I've did it with "include into" and use a normal string variable, but IMHO this
gives the same result as using save output(_request{"sidebar"})
>
> This is needlessly complex and requires you to put this in every content
> circuit, so I wouldn't recommend it.
Yes, I've already found, that this approach requires me to put this in every
content circuit, which isn't quite elegant.
>
> Or instead of doing this, an easier (and perhaps better) way is to "cheat"
> and put the code to generate the sidebar in files that are included from the
> layout, this creating your own pseudo-circuit, like this:
>
> // in layout
> include("/sidebar/qry_sidebar.a4d")
> include("/sidebar/dsp_sidebar.a4d")
I was close to this with my second suggestion. My mental block was, that I
tried to "run" the circuit from the layout with sendfuseaction or redirect,
which both make things overly complicated. Simply including the files is an
elegant solution. You call this cheating and pseudo-circuit as in puristic
Fusebox design, you shouldn't include act_ or qry_ files into the layout file?
Would you suggest to use this approach for any dynamic content outside of the
main area?
Let's say I'd spice up your bicycle online store (the screencast) with a
categories popup in the left sidebar, build from a 4D database and a right
sidebar holding two dynamic areas, a condensed view of the shopping cart and a
related products list, dynamically created depending on the selection you make
in the main area. Would you incorporate these parts with this pseudo-circuit
mechanism within the layout file for left:sidebar and right_sidebar?
> Nesting a circuit is useful if you have a different layout in the other
> circuit and the other circuit is a kind of plugin that the main page doesn't
> know anything about.
Hmm, I read this sentence about 20 times but still don't understand, what you
exactly mean with this.
You refer to my question about benefit of nested circuits. "Other circuit" is
the nested circuit, right? Aren't nested circuits always a kind of plugins as
long as they create an output? And how can the main page (output of the parent
circuit, or output of the root circuit ? ) know nothing about that nested
circuit. Each circuit has to be registered in fbx_circuits to be accessible, so
the fusebox application has to know about the nested circuit.
Finally, in the screencast you start with a static page from the designer, tear
this apart into individual files and finally replace the static content with
dynamic content. While the site in the screencast doesn't use Fusebox, would
you use a similar approach to design this site in Fusebox, aka. design one or
more static pages, put the individual parts (divs) into seperate Fusebox layout
files, then substitute the static content with dynamically created content via
dsp_ files?
Or do you design the layouts initially from scratch and rely on Fusebox to
preview the output, while styling the site?
Pete
_______________________________________________
Active4D-dev mailing list
[email protected]
http://list.aparajitaworld.com/listinfo/active4d-dev
Archives: http://vasudev.aparajitaworld.com/archive/active4d-dev/
