useage case found for WFPageDelegate::didRenderPage
閲覧: 1 回
最初の未読メッセージにスキップ
SwissalpS
2010/08/16 23:03:282010/08/16
To: phocoa users
I'm working on a multilingual website.
The translated portions come from a mySQl database interfaced with
propel.
We have a lot of umlauts and other special characters to deal with.
There wasn't a problem until I started loading portions via ajax.
Example:
I have a disclaimer which can be read by visiting http://example.com/disclaimer
It shows up in the current language.
I also have a page set up with WFYAHOO_widget_Tab in
WFYAHOO_widget_TabView.
I've set the dataSrc property of the tab to /disclaimer
when one clicks on the tab, the content is loaded, but the special
chars are all wrong.
certainly best practice tells us to convert special chars on input to
the database, but a) db handles them perfectly and b) we already have
quite a few templates which also contain these chars.
So the least painful solution to my current problem was to use
didRenderPage function and clean the full output like so:
// unfortunately str_replace does not find them...
public function didRenderPage($oPage, $aParameters, &$sOutput) {
$sNew = '';
$iLen = mb_strlen($sOutput);
for ($j = 0; $j < $iLen; $j++) {
$s = mb_substr($sOutput, $j, 1);
$i = ord($s);
switch ($i) {
// tab, nl, cr
case 9 :
case 10 :
case 13 :
// other ascii chars
case ($i < 127 && $i > 31) :
// they are fine, just append
$sNew .= $s;
break;
default:
// any others need to be 'escaped'
$sNew .= '&#' . $i . ';';
} // switch char value
} // foreach char
$sOutput = $sNew;
} // didRenderPage
The translated portions come from a mySQl database interfaced with
propel.
We have a lot of umlauts and other special characters to deal with.
There wasn't a problem until I started loading portions via ajax.
Example:
I have a disclaimer which can be read by visiting http://example.com/disclaimer
It shows up in the current language.
I also have a page set up with WFYAHOO_widget_Tab in
WFYAHOO_widget_TabView.
I've set the dataSrc property of the tab to /disclaimer
when one clicks on the tab, the content is loaded, but the special
chars are all wrong.
certainly best practice tells us to convert special chars on input to
the database, but a) db handles them perfectly and b) we already have
quite a few templates which also contain these chars.
So the least painful solution to my current problem was to use
didRenderPage function and clean the full output like so:
// unfortunately str_replace does not find them...
public function didRenderPage($oPage, $aParameters, &$sOutput) {
$sNew = '';
$iLen = mb_strlen($sOutput);
for ($j = 0; $j < $iLen; $j++) {
$s = mb_substr($sOutput, $j, 1);
$i = ord($s);
switch ($i) {
// tab, nl, cr
case 9 :
case 10 :
case 13 :
// other ascii chars
case ($i < 127 && $i > 31) :
// they are fine, just append
$sNew .= $s;
break;
default:
// any others need to be 'escaped'
$sNew .= '&#' . $i . ';';
} // switch char value
} // foreach char
$sOutput = $sNew;
} // didRenderPage
SwissalpS
2010/08/16 23:17:102010/08/16
To: phocoa users
one more thing...
I have two tabs. There is a bug or I have not understood something.
If I set the dataSrc property of the second tab without setting a
dataSrc for the first (static content)
and load the page:
first tab is active and shows static content - fine.
click on second tab expecting it to load from dataSrc
but nothing is displayed
click on first tab expecting static content to reapear
oops, now it loads from dataSrc and displays the content I was
expecting in second tab.
This can be reconstructed with other properties too.
I first discovered this 'bug' when I wanted to diactivate/disable a
third tab. All showed as if nothing was disabled until I wanted to
switch back to initial first tab: now this one was disabled.
The solution is to set the same property for all tabs if you want to
set the property.
So it's either all static tabs or all dynamically loaded tabs, but not
mixed.
On Aug 17, 5:03 am, SwissalpS <luke.swissa...@gmail.com> wrote:
> I'm working on a multilingual website.
> The translated portions come from a mySQl database interfaced with
> propel.
> We have a lot of umlauts and other special characters to deal with.
> There wasn't a problem until I started loading portions via ajax.
> Example:
> I have a disclaimer which can be read by visitinghttp://example.com/disclaimer
I have two tabs. There is a bug or I have not understood something.
If I set the dataSrc property of the second tab without setting a
dataSrc for the first (static content)
and load the page:
first tab is active and shows static content - fine.
click on second tab expecting it to load from dataSrc
but nothing is displayed
click on first tab expecting static content to reapear
oops, now it loads from dataSrc and displays the content I was
expecting in second tab.
This can be reconstructed with other properties too.
I first discovered this 'bug' when I wanted to diactivate/disable a
third tab. All showed as if nothing was disabled until I wanted to
switch back to initial first tab: now this one was disabled.
The solution is to set the same property for all tabs if you want to
set the property.
So it's either all static tabs or all dynamically loaded tabs, but not
mixed.
On Aug 17, 5:03 am, SwissalpS <luke.swissa...@gmail.com> wrote:
> I'm working on a multilingual website.
> The translated portions come from a mySQl database interfaced with
> propel.
> We have a lot of umlauts and other special characters to deal with.
> There wasn't a problem until I started loading portions via ajax.
> Example:
Alan Pinstein
2010/08/16 23:25:162010/08/16
To: phocoa...@googlegroups.com
Are you giving unique ID's to each tab? There could be a bug, maybe
there is some shared state or something.
there is some shared state or something.
Just be sure that a) you're defining N tabs in the YAML, and b) you're
correctly using *each* only once in the TPL.
Alan
> --
> You received this message because you are subscribed to the Google
> Groups "phocoa users" group.
> To post to this group, send email to phocoa...@googlegroups.com.
> To unsubscribe from this group, send email to phocoa-users...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/phocoa-users?hl=en
> .
>
Alan Pinstein
2010/08/16 23:26:182010/08/16
To: phocoa...@googlegroups.com
Hmm, that can't be the right solution.
I have not personally dealt with encodings too much, esp across ajax,
but I'd suspect that they are treated just like any other DOM content.
Are you sure that the encoding on the host page is set correct? Do you
know exactly where it's loosing the encoding?
Alan
SwissalpS
2010/08/17 0:40:592010/08/17
To: phocoa users
the action can currently be seen at:
http://skypromenade.phocoa.lukezimmermann.com/bridge/listall
http://skypromenade.phocoa.lukezimmermann.com/disclaimer
in tabs:
http://skypromenade.phocoa.lukezimmermann.com/bridge/list
my cleaner workaround doesn't help entirely. The umlauts are converted
correctly now, but the following chars get messed up.
I am working on the above mentioned pages, making sure I have the
points you mentioned correct... might change or show an error msg.
It'll be gone in a mo as I'm 'on it' :)
SwissalpS
2010/08/17 0:58:142010/08/17
To: phocoa users
found another curious occurance:
to avoid needing to put the above cleaner in every page delegate, I
made a function in the SssSBla class
static function cleanText(&$sOutput) {
// the above process here
}
this was the cause of messed up chars after a special char.
With the loop in each module it 'works' = slow but output ok.
I also tried without passing by reference:
static function cleanText($sOutput) {
// the above process here
return $sClean;
}
but that wasn't any better. Somehow PHP seems to mess with the string
that is passed along. I would try to clone but this is really not the
way I would need to treat the output.
What happened with utf-8 all the way? argh, I might lose my 'bet'
because of this.
On Aug 17, 5:26 am, Alan Pinstein <apinst...@mac.com> wrote:
> Hmm, that can't be the right solution.
>
> I have not personally dealt with encodings too much, esp across ajax,
> but I'd suspect that they are treated just like any other DOM content.
>
> Are you sure that the encoding on the host page is set correct? Do you
> know exactly where it's loosing the encoding?
> Alan
>
> On Aug 16, 2010, at 11:03 PM, SwissalpS wrote:
>
>
>
> > I'm working on a multilingual website.
> > The translated portions come from a mySQl database interfaced with
> > propel.
> > We have a lot of umlauts and other special characters to deal with.
> > There wasn't a problem until I started loading portions via ajax.
> > Example:
> > I have a disclaimer which can be read by visitinghttp://example.com/disclaimer
to avoid needing to put the above cleaner in every page delegate, I
made a function in the SssSBla class
static function cleanText(&$sOutput) {
// the above process here
}
this was the cause of messed up chars after a special char.
With the loop in each module it 'works' = slow but output ok.
I also tried without passing by reference:
static function cleanText($sOutput) {
// the above process here
return $sClean;
}
but that wasn't any better. Somehow PHP seems to mess with the string
that is passed along. I would try to clone but this is really not the
way I would need to treat the output.
What happened with utf-8 all the way? argh, I might lose my 'bet'
because of this.
On Aug 17, 5:26 am, Alan Pinstein <apinst...@mac.com> wrote:
> Hmm, that can't be the right solution.
>
> I have not personally dealt with encodings too much, esp across ajax,
> but I'd suspect that they are treated just like any other DOM content.
>
> Are you sure that the encoding on the host page is set correct? Do you
> know exactly where it's loosing the encoding?
> Alan
>
> On Aug 16, 2010, at 11:03 PM, SwissalpS wrote:
>
>
>
> > I'm working on a multilingual website.
> > The translated portions come from a mySQl database interfaced with
> > propel.
> > We have a lot of umlauts and other special characters to deal with.
> > There wasn't a problem until I started loading portions via ajax.
> > Example:
SwissalpS
2010/08/17 1:14:582010/08/17
To: phocoa users
list.tpl:
{WFViewBlock id="myTabs"}
{WFViewBlock id="SssSmain"}{WFView id=guestContent}{SssSBla
value="TODObridgeListGuest"}{/WFViewBlock}
{WFViewBlock id="SssSguest"}{/WFViewBlock}
{/WFViewBlock}
list.yaml:
guestContent:
class: WFLabel
myTabs :
children:
SssSguest:
class : WFYAHOO_widget_Tab
properties:
dataSrc: /disclaimer
SssSmain :
class: WFYAHOO_widget_Tab
class : WFYAHOO_widget_TabView
bridge.php
class module_bridge_list {
function parameterList() {
return array('section');
}
function parametersDidLoad($oPage, $aParams) {
// make sure there is a section selected
if (!isset($aParams['section'])) $aParams['section'] = 'SssSmain';
// select the correct tab
$oPage->outlet('myTabs')->setValueForKey($aParams['section'],
'selectedTabId');
} // parametersDidLoad
....
that is how I have it set up now and will leave it that way (for a
couple of hours) to show that the dataSrc gets loaded into the wrong
tab
{WFViewBlock id="myTabs"}
{WFViewBlock id="SssSmain"}{WFView id=guestContent}{SssSBla
value="TODObridgeListGuest"}{/WFViewBlock}
{WFViewBlock id="SssSguest"}{/WFViewBlock}
{/WFViewBlock}
list.yaml:
guestContent:
class: WFLabel
myTabs :
children:
SssSguest:
class : WFYAHOO_widget_Tab
properties:
dataSrc: /disclaimer
SssSmain :
class: WFYAHOO_widget_Tab
class : WFYAHOO_widget_TabView
bridge.php
class module_bridge_list {
function parameterList() {
return array('section');
}
function parametersDidLoad($oPage, $aParams) {
// make sure there is a section selected
if (!isset($aParams['section'])) $aParams['section'] = 'SssSmain';
// select the correct tab
$oPage->outlet('myTabs')->setValueForKey($aParams['section'],
'selectedTabId');
} // parametersDidLoad
....
that is how I have it set up now and will leave it that way (for a
couple of hours) to show that the dataSrc gets loaded into the wrong
tab
> Hmm, that can't be the right solution.
>
> I have not personally dealt with encodings too much, esp across ajax,
> but I'd suspect that they are treated just like any other DOM content.
>
> Are you sure that the encoding on the host page is set correct? Do you
> know exactly where it's loosing the encoding?
> Alan
>
> On Aug 16, 2010, at 11:03 PM, SwissalpS wrote:
>
>
>
> > I'm working on a multilingual website.
> > The translated portions come from a mySQl database interfaced with
> > propel.
> > We have a lot of umlauts and other special characters to deal with.
> > There wasn't a problem until I started loading portions via ajax.
> > Example:
> > I have a disclaimer which can be read by visitinghttp://example.com/disclaimer
>
> I have not personally dealt with encodings too much, esp across ajax,
> but I'd suspect that they are treated just like any other DOM content.
>
> Are you sure that the encoding on the host page is set correct? Do you
> know exactly where it's loosing the encoding?
> Alan
>
> On Aug 16, 2010, at 11:03 PM, SwissalpS wrote:
>
>
>
> > I'm working on a multilingual website.
> > The translated portions come from a mySQl database interfaced with
> > propel.
> > We have a lot of umlauts and other special characters to deal with.
> > There wasn't a problem until I started loading portions via ajax.
> > Example:
SwissalpS
2010/08/17 1:27:592010/08/17
To: phocoa users
I'm getting tired: the problem here, is not the refactoring. I had
added , 'UTF-8' to mb_substring that messed the chars up.
my database is utf-8 and so is my php. I don't have the doctype
declaration (that shouldn't hurt as no browsers actually need that
tag, they mostly do a better job without it.)
added , 'UTF-8' to mb_substring that messed the chars up.
my database is utf-8 and so is my php. I don't have the doctype
declaration (that shouldn't hurt as no browsers actually need that
tag, they mostly do a better job without it.)
Alan Pinstein
2010/08/17 13:52:242010/08/17
To: phocoa...@googlegroups.com
So you figured it out?
SwissalpS
2010/08/17 14:05:122010/08/17
To: phocoa users
nope, the utf-8 stuff somewhat, I have run a script over night to
convert all .tpl and db entries
the fact that I can't have second tab use dataSrc and first one load
dynamic is still a riddle to me.
convert all .tpl and db entries
the fact that I can't have second tab use dataSrc and first one load
dynamic is still a riddle to me.
Alan Pinstein
2010/08/17 20:48:322010/08/17
To: phocoa...@googlegroups.com
Oh, you're right!
There was a bug in the code that set up the tabs. If one of the tabs
had *no* config then the config for the *next* tab would be applied to
the one before it. Also I fixed a bug where the dataSrc content
wouldn't automatically load on the selected tab.
I have committed & pushed:
http://github.com/apinstein/phocoa/commit/5ed841ab3df1c8d3cb79042749964a540fc0f9b6
Enjoy!
Alan
SwissalpS
2010/08/18 8:11:552010/08/18
To: phocoa users
Thanks a lot. That solved the 'off-topic' issue :-D
works fine now with disabling arbitrary tab and dynamicaly loading
content in the second tab and 'statically' loading first.
Great!
Luke
On Aug 18, 2:48 am, Alan Pinstein <apinst...@mac.com> wrote:
> Oh, you're right!
>
> There was a bug in the code that set up the tabs. If one of the tabs
> had *no* config then the config for the *next* tab would be applied to
> the one before it. Also I fixed a bug where the dataSrc content
> wouldn't automatically load on the selected tab.
>
> I have committed & pushed:
>
> http://github.com/apinstein/phocoa/commit/5ed841ab3df1c8d3cb790427499...
works fine now with disabling arbitrary tab and dynamicaly loading
content in the second tab and 'statically' loading first.
Great!
Luke
On Aug 18, 2:48 am, Alan Pinstein <apinst...@mac.com> wrote:
> Oh, you're right!
>
> There was a bug in the code that set up the tabs. If one of the tabs
> had *no* config then the config for the *next* tab would be applied to
> the one before it. Also I fixed a bug where the dataSrc content
> wouldn't automatically load on the selected tab.
>
> I have committed & pushed:
>
Alan Pinstein
2010/08/18 9:02:132010/08/18
To: phocoa...@googlegroups.com
Yeah, that was a stupid bug! I don't think I've ever used tabs in a
way to trigger that bug. Although, tabs have always acted wonky, I
wonder if I just fixed it! I will have to see.
way to trigger that bug. Although, tabs have always acted wonky, I
wonder if I just fixed it! I will have to see.
Alan
全員に返信
投稿者に返信
転送
新着メール 0 件