Persisting content acquired in a block across all blocks
Permalink
I'm a newbie to Concrete5.
I have some code which uses REST to pull down some text from a server. I want to store the text locally and then have it appear wherever a macro-like string falls in the text of the site.
For example, if I markup the text with {myText1} I would want the code which does the REST call be executed very early in the render process, and then for the rendering to find {myText1} and replace it with the RESTed text.
Any ideas how to achieve this?
I have some code which uses REST to pull down some text from a server. I want to store the text locally and then have it appear wherever a macro-like string falls in the text of the site.
For example, if I markup the text with {myText1} I would want the code which does the REST call be executed very early in the render process, and then for the rendering to find {myText1} and replace it with the RESTed text.
Any ideas how to achieve this?
What do you mean "if I markup the text with {myText1}". I'd need more detail about how and where you are using this markup. Do you mean the text in a Content block, the text in a page_type file, the text in an HTML block, the text on a single_page, the text in a block template, etc. There are many, many, places you could put this markup, but ease of coding a solution is dependent on that place.
Basically anywhere. The idea is that the client has the freedom to place the
text wherever. As I think about it, is there the possibility of being able
to enumerate all the elements on the page, get the content of each, and make
the swap? Alternatively, is there some point where one can interpose code
just before the rendering process sends its output to the browser?
Bruce.
text wherever. As I think about it, is there the possibility of being able
to enumerate all the elements on the page, get the content of each, and make
the swap? Alternatively, is there some point where one can interpose code
just before the rendering process sends its output to the browser?
Bruce.
Why wouldn't a simple custom block work? For that matter, you might be able to hack the HTML block to do what you want as a "quick and dirty" approach.
-Steve
-Steve
I've already tried the QAD approach and it works (at least for the pure javascript incarnation). However, it's an approach that doesn't survive system updates very well.
So, yes, I can subvert Concrete5, and have done so successfully. However, I'd much prefer to work within the box, and thus have access to all the expressive power of Concrete5.
So, yes, I can subvert Concrete5, and have done so successfully. However, I'd much prefer to work within the box, and thus have access to all the expressive power of Concrete5.
Sure, everything you ask is possible.
I would normally attack this issue from a different perspective, but I don't really know much about what or why you need this {myText1} variable. You could replace {myText1} via a server side (pre-browser) parsing, or even with javascript (AJAX even). So really the sky is the limit. As to which method is best would depend on the situation.
The easiest solution (I think) would be to replace any instance of your markup via jQuery (JS). Leave the server out of the equation..
Basically you'd dump the results of your REST query into a JS variable, then replace() {myText1} with the variable.
Again, hard to really say without knowing more about the situation.
I would normally attack this issue from a different perspective, but I don't really know much about what or why you need this {myText1} variable. You could replace {myText1} via a server side (pre-browser) parsing, or even with javascript (AJAX even). So really the sky is the limit. As to which method is best would depend on the situation.
The easiest solution (I think) would be to replace any instance of your markup via jQuery (JS). Leave the server out of the equation..
Basically you'd dump the results of your REST query into a JS variable, then replace() {myText1} with the variable.
Again, hard to really say without knowing more about the situation.
I agree -- there are ways to do this but it might not be the best thing to do. Could you provide more details about what your exact situation is? Perhaps we could offer a more "concrete-like" approach?
I'd be interested to see how a javascript replace approach would work the way you describe.
At this point in the project I'm not using the {variableName} approach at all, but rather changing the innerHTML of a span from a default hard-coded value to the value that I pull down from the server using a synthetic <script>. The downside of that approach is that the person using the browser occasionally sees the hard-coded value briefly before the innerHTML substitution takes place.
I would prefer to have the value substitution happen on the server so that this "now you see it, now you don't" issue is avoided. And thus the move away from innerHTML to symbol substitution at the pre-browser level.
At this point in the project I'm not using the {variableName} approach at all, but rather changing the innerHTML of a span from a default hard-coded value to the value that I pull down from the server using a synthetic <script>. The downside of that approach is that the person using the browser occasionally sees the hard-coded value briefly before the innerHTML substitution takes place.
I would prefer to have the value substitution happen on the server so that this "now you see it, now you don't" issue is avoided. And thus the move away from innerHTML to symbol substitution at the pre-browser level.
> The downside of that approach is that the person using the
> browser occasionally sees the hard-coded value briefly
If that's the only downside, then why not have the tag be empty by default?
-Steve
> browser occasionally sees the hard-coded value briefly
If that's the only downside, then why not have the tag be empty by default?
-Steve
Because there has to be a value there for those situations where javascript
has been disabled, or the server against which the synthetic script call is
made is down.
has been disabled, or the server against which the synthetic script call is
made is down.
> You could replace {myText1} via a server side (pre-browser) parsing
That sounds like what I need. How do I get a hold of the text of the current page before it's passed to the browser?
That sounds like what I need. How do I get a hold of the text of the current page before it's passed to the browser?
I don't think you can get a hold of the whole page before output -- C5 is totally based on block output. And you'll have to hack into the system to make this work (check out the end of the render() function in concrete/libraries/block_view.php -- maybe you could do a string replacement on the $outputContent variable?). Or perhaps a cleaner solution is to start an output buffer at the top of your page templates and then get contents at the end and do the string replacement, then output the modified buffer (seehttp://php.net/manual/en/book.outcontrol.php... ).
Again, if you could explain more about what it is exactly you want to do this for, we might be able to offer an alternate solution that doesn't involved hacking the system.
Again, if you could explain more about what it is exactly you want to do this for, we might be able to offer an alternate solution that doesn't involved hacking the system.
In "/concrete/libraries/view.php line 773 is
This is the point where the page is fully composed and output to the browser. I've hooked this for Miser (just intercepted it), but I'm looking at generating an event and passing the contents now since that is far more flexible for all the other gadgets I have in the pipeline.
print $pageContent;
This is the point where the page is fully composed and output to the browser. I've hooked this for Miser (just intercepted it), but I'm looking at generating an event and passing the contents now since that is far more flexible for all the other gadgets I have in the pipeline.
