You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Danny Robinson <da...@gmail.com> on 2007/07/13 16:30:55 UTC
[Trinidad] tr:messages Component Refresh
Does anyone use the the existing skin selectors for
af|messages::top-start-icon etc., which allow the component to have rounded
corners etc? The 'laf' implementation of this seems cumbersome and not
something especially specific to the tr:messages component. It would seem
better to have a generic Renderer that we could delegate to for this similar
to the roundedDiv component.
So I guess I'm asking if anyone would mind if we disabled these selectors
(af|messages::top-start-icon etc. styles ) until a cleaner solution was
available?
--
Chordiant Software Inc.
www.chordiant.com
Re: [Trinidad] tr:messages Component Refresh
Posted by Danny Robinson <da...@gmail.com>.
That works great - thanks Simon.
On 7/13/07, Simon Lessard <si...@gmail.com> wrote:
>
> Danny,
>
> You can simply push a skinResourceKeyMap on the RenderingContext to
> redirect selector names to redirect selector names.
>
>
> Regards,
>
> ~ Simon
>
> On 7/13/07, Danny Robinson <da...@gmail.com> wrote:
> >
> > That could work, but we'd definately want to override the default skin
> > selectors being used by PanelBoxRenderer. Would anyone be opposed to having
> > some getBoxTopStartStyle(), getBoxBottomEndStyle() methods that could be
> > overridden by MessageBoxRenderer?
> >
> >
> > On 7/13/07, Adam Winer < awiner@gmail.com> wrote:
> > >
> > > What if we delegate MessagesRenderer to PanelBoxRenderer,
> > > and use the same pattern of skin selectors?
> > >
> > > -- Adam
> > >
> > >
> > >
> > >
> > > On 7/13/07, Danny Robinson < dannyjrobinson@gmail.com > wrote:
> > > > Does anyone use the the existing skin selectors for
> > > > af|messages::top-start-icon etc., which allow the component to have
> > > rounded
> > > > corners etc? The 'laf' implementation of this seems cumbersome and
> > > not
> > > > something especially specific to the tr:messages component. It
> > > would seem
> > > > better to have a generic Renderer that we could delegate to for this
> > > similar
> > > > to the roundedDiv component.
> > > >
> > > > So I guess I'm asking if anyone would mind if we disabled these
> > > selectors
> > > > (af|messages::top-start-icon etc. styles ) until a cleaner solution
> > > was
> > > > available?
> > > >
> > > >
> > > > --
> > > > Chordiant Software Inc.
> > > > www.chordiant.com
> > >
> >
> >
> >
> > --
> > Chordiant Software Inc.
> > www.chordiant.com
> >
>
>
--
Chordiant Software Inc.
www.chordiant.com
Re: [Trinidad] tr:messages Component Refresh
Posted by Simon Lessard <si...@gmail.com>.
Danny,
You can simply push a skinResourceKeyMap on the RenderingContext to redirect
selector names to redirect selector names.
Regards,
~ Simon
On 7/13/07, Danny Robinson <da...@gmail.com> wrote:
>
> That could work, but we'd definately want to override the default skin
> selectors being used by PanelBoxRenderer. Would anyone be opposed to having
> some getBoxTopStartStyle(), getBoxBottomEndStyle() methods that could be
> overridden by MessageBoxRenderer?
>
>
> On 7/13/07, Adam Winer <aw...@gmail.com> wrote:
> >
> > What if we delegate MessagesRenderer to PanelBoxRenderer,
> > and use the same pattern of skin selectors?
> >
> > -- Adam
> >
> >
> >
> >
> > On 7/13/07, Danny Robinson <dannyjrobinson@gmail.com > wrote:
> > > Does anyone use the the existing skin selectors for
> > > af|messages::top-start-icon etc., which allow the component to have
> > rounded
> > > corners etc? The 'laf' implementation of this seems cumbersome and
> > not
> > > something especially specific to the tr:messages component. It would
> > seem
> > > better to have a generic Renderer that we could delegate to for this
> > similar
> > > to the roundedDiv component.
> > >
> > > So I guess I'm asking if anyone would mind if we disabled these
> > selectors
> > > (af|messages::top-start-icon etc. styles ) until a cleaner solution
> > was
> > > available?
> > >
> > >
> > > --
> > > Chordiant Software Inc.
> > > www.chordiant.com
> >
>
>
>
> --
> Chordiant Software Inc.
> www.chordiant.com
>
Re: [Trinidad] tr:messages Component Refresh
Posted by Danny Robinson <da...@gmail.com>.
That could work, but we'd definately want to override the default skin
selectors being used by PanelBoxRenderer. Would anyone be opposed to having
some getBoxTopStartStyle(), getBoxBottomEndStyle() methods that could be
overridden by MessageBoxRenderer?
On 7/13/07, Adam Winer <aw...@gmail.com> wrote:
>
> What if we delegate MessagesRenderer to PanelBoxRenderer,
> and use the same pattern of skin selectors?
>
> -- Adam
>
>
>
>
> On 7/13/07, Danny Robinson <da...@gmail.com> wrote:
> > Does anyone use the the existing skin selectors for
> > af|messages::top-start-icon etc., which allow the component to have
> rounded
> > corners etc? The 'laf' implementation of this seems cumbersome and not
> > something especially specific to the tr:messages component. It would
> seem
> > better to have a generic Renderer that we could delegate to for this
> similar
> > to the roundedDiv component.
> >
> > So I guess I'm asking if anyone would mind if we disabled these
> selectors
> > (af|messages::top-start-icon etc. styles ) until a cleaner solution was
> > available?
> >
> >
> > --
> > Chordiant Software Inc.
> > www.chordiant.com
>
--
Chordiant Software Inc.
www.chordiant.com
Re: [Trinidad] tr:messages Component Refresh
Posted by Simon Lessard <si...@gmail.com>.
On 7/13/07, Adam Winer <aw...@gmail.com> wrote:
>
> What if we delegate MessagesRenderer to PanelBoxRenderer,
> and use the same pattern of skin selectors?
+1, at least until 2030 when MSIE 15 is going to support 90% of CSS 3
(including round corners hopefully).
-- Adam
>
>
>
>
> On 7/13/07, Danny Robinson <da...@gmail.com> wrote:
> > Does anyone use the the existing skin selectors for
> > af|messages::top-start-icon etc., which allow the component to have
> rounded
> > corners etc? The 'laf' implementation of this seems cumbersome and not
> > something especially specific to the tr:messages component. It would
> seem
> > better to have a generic Renderer that we could delegate to for this
> similar
> > to the roundedDiv component.
> >
> > So I guess I'm asking if anyone would mind if we disabled these
> selectors
> > (af|messages::top-start-icon etc. styles ) until a cleaner solution was
> > available?
> >
> >
> > --
> > Chordiant Software Inc.
> > www.chordiant.com
>
Re: [Trinidad] tr:messages Component Refresh
Posted by Adam Winer <aw...@gmail.com>.
What if we delegate MessagesRenderer to PanelBoxRenderer,
and use the same pattern of skin selectors?
-- Adam
On 7/13/07, Danny Robinson <da...@gmail.com> wrote:
> Does anyone use the the existing skin selectors for
> af|messages::top-start-icon etc., which allow the component to have rounded
> corners etc? The 'laf' implementation of this seems cumbersome and not
> something especially specific to the tr:messages component. It would seem
> better to have a generic Renderer that we could delegate to for this similar
> to the roundedDiv component.
>
> So I guess I'm asking if anyone would mind if we disabled these selectors
> (af|messages::top-start-icon etc. styles ) until a cleaner solution was
> available?
>
>
> --
> Chordiant Software Inc.
> www.chordiant.com
Re: TRINIDAD : PPR functionality broken on PDA
Posted by Adam Winer <aw...@gmail.com>.
The PPR code has been completely overhauled from
an IFRAME-based system to an XMLHttp-based system.
The prior PDA code was a pseudo XMLHttp fork, and
is very intentionally gone, since now everything is
XMLHttp. It'd be great to have code contributions
to get PDA functional again, but not by just re-adding
the old code.
-- Adam
On 7/13/07, Piyush Hari <pi...@oracle.com> wrote:
> Hello,
>
> This is fairly urgent. I was working on Trinidad -103 : showDetail and
> showDetailsHeader components don't work on PDAs and realised that
> Partial submitis totally broken across all components on PDAs.
> Previously, we had it working with the following components supporting
> PPR on PDAs:
>
> showDetail
> shoeDetailHeader
> input
> select components
> Table
>
> As a result, components like showDetail and showDetailHeader have been
> broken. Clicking them neither submits the form fully nor partially.
>
> Any insights into this ? The code seem to have been substantially
> refactored since I last delved into it.
>
> The reason appears to be the modifications made to Core.js where the
> following PDA specific code no more exists :
>
> if (_agent.isPIE)
> {
> var isPartialForPIE = false;
> var partialTargets = parameters["partialTargets"];
> var partial = parameters["partial"];
> if ((partialTargets != (void 0)) || (partial != (void 0)))
> {
> var data = "";
> data = createNameValueString(form);
> var useragent = navigator.userAgent;
> try
> {
> XmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
> }
> catch(e)
> {
> XmlHttp = null;
> XmlRequest = null;
> var errnum = e.number & 0xFFFFFF;
> if (errnum == 655789)
> {
> alert("\"Run ActiveX controls and plug-ins\" and \"Script
> ActiveX controls marked safe for scripting\" must be enabled!");
> }
> }
> if( XmlHttp == null)
> {
> form.target="_self";
> form.submit();
> return doSubmit;
> }
> else
> {
> var urlenc = "application/x-www-form-urlencoded; charset=utf-8";
> XmlHttp.open (form.method.toUpperCase(), form.action, false);
> XmlHttp.setRequestHeader ("Content-Type", urlenc);
> XmlHttp.setRequestHeader ("User-Agent", useragent);
> try
> {
> XmlHttp.send(data);
> }
> catch (e)
> {
> XmlHttp.open (form.method.toUpperCase(), form.action, false);
> XmlHttp.setRequestHeader ("Content-Type", urlenc);
> XmlHttp.setRequestHeader ("User-Agent", useragent);
> XmlHttp.send(data);
> }
> var responseString = new String(XmlHttp.responseText);
> try
> {
> xmlDOC = new ActiveXObject("Microsoft.XMLDOM");
> xmlDOC.loadXML(responseString.toString());
> }
> catch (e)
> {
> form.target="_self";
> form.submit();
> return doSubmit;
> }
> try
> {
> var root = xmlDOC.documentElement;
> var pprscriptnodes = root.selectNodes("//pprscripts");
> var pprscript =
> pprscriptnodes.item(0).childNodes.item(0).nodeTypedValue;
> var pprtargetnodes = root.selectNodes("//pprtargets/pprtarget");
> for (var i = 0; i < pprtargetnodes.length; i++)
> {
> var origpprtargetid =
> pprtargetnodes.item(i).attributes(0).text;
> var tructargetid;
> var ind = origpprtargetid.indexOf("__xc");
> if (ind > -1 )
> {
> tructargetid = origpprtargetid.substring(0,ind);
> }
> else
> {
> tructargetid = origpprtargetid;
> }
> var pprnode = root.selectNodes("//ppr[@target_id='"
> + tructargetid
> + "']");
> if ((pprnode != null) && (pprnode != (void 0)))
> {
> try
> {
> var pprtext =
> pprnode.item(0).childNodes.item(0).nodeTypedValue;
> var newpprtext = pprtext.toString();
> if ((pprtext.indexOf("span") > -1)
> || (pprtext.indexOf("div") > -1))
> {
> var re = new RegExp ('\\s*id\\s*=\\s*"'
> + origpprtargetid
> + '"\\s*', "gi");
> //var re =new
> RegExp('span\\s*id\\s*=\\s*"(.*?)"\\s*',"gi");
> newpprtext = pprtext.replace(re,' id="'
> + origpprtargetid
> + '_ppr_" ');
> // newpprtext = pprtext.replace(re,'span
> id="$1_ppr_" ');
> }
> // alert(origpprtargetid + " " + tructargetid + " "
> // + i + " " +newpprtext);
> eval("window['"
> + origpprtargetid
> +
> "'].innerHTML=newpprtext+'<script>'+pprscript+'</script>'");
> }
> catch(e)
> {
> // alert("exception here" + e.message);
> }
> }
> }
> }
> catch (e)
> {
>
> var elem = form.elements["partial"];
> elem.value="";
> form.target="_self";
> form.submit();
> return doSubmit;
> }
> finally
> {
> xmlHttp = null;
> xmlDoc = null;
> responseString = null;
> root = null;
> }
> }
> }
> else
> {
> form.target="_self";
> form.submit();
> return doSubmit;
> }
> }
> else // ! (_agent.isPIE)
> {
> form.submit();
> if (_blockOnEverySubmit)
> _pprStartBlocking(window);
> }
>
> Can this be fixed any sooner ?
>
> Regards,
> Piyush
>
>
TRINIDAD : PPR functionality broken on PDA
Posted by Piyush Hari <pi...@oracle.com>.
Hello,
This is fairly urgent. I was working on Trinidad -103 : showDetail and
showDetailsHeader components don't work on PDAs and realised that
Partial submitis totally broken across all components on PDAs.
Previously, we had it working with the following components supporting
PPR on PDAs:
showDetail
shoeDetailHeader
input
select components
Table
As a result, components like showDetail and showDetailHeader have been
broken. Clicking them neither submits the form fully nor partially.
Any insights into this ? The code seem to have been substantially
refactored since I last delved into it.
The reason appears to be the modifications made to Core.js where the
following PDA specific code no more exists :
if (_agent.isPIE)
{
var isPartialForPIE = false;
var partialTargets = parameters["partialTargets"];
var partial = parameters["partial"];
if ((partialTargets != (void 0)) || (partial != (void 0)))
{
var data = "";
data = createNameValueString(form);
var useragent = navigator.userAgent;
try
{
XmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
}
catch(e)
{
XmlHttp = null;
XmlRequest = null;
var errnum = e.number & 0xFFFFFF;
if (errnum == 655789)
{
alert("\"Run ActiveX controls and plug-ins\" and \"Script
ActiveX controls marked safe for scripting\" must be enabled!");
}
}
if( XmlHttp == null)
{
form.target="_self";
form.submit();
return doSubmit;
}
else
{
var urlenc = "application/x-www-form-urlencoded; charset=utf-8";
XmlHttp.open (form.method.toUpperCase(), form.action, false);
XmlHttp.setRequestHeader ("Content-Type", urlenc);
XmlHttp.setRequestHeader ("User-Agent", useragent);
try
{
XmlHttp.send(data);
}
catch (e)
{
XmlHttp.open (form.method.toUpperCase(), form.action, false);
XmlHttp.setRequestHeader ("Content-Type", urlenc);
XmlHttp.setRequestHeader ("User-Agent", useragent);
XmlHttp.send(data);
}
var responseString = new String(XmlHttp.responseText);
try
{
xmlDOC = new ActiveXObject("Microsoft.XMLDOM");
xmlDOC.loadXML(responseString.toString());
}
catch (e)
{
form.target="_self";
form.submit();
return doSubmit;
}
try
{
var root = xmlDOC.documentElement;
var pprscriptnodes = root.selectNodes("//pprscripts");
var pprscript =
pprscriptnodes.item(0).childNodes.item(0).nodeTypedValue;
var pprtargetnodes = root.selectNodes("//pprtargets/pprtarget");
for (var i = 0; i < pprtargetnodes.length; i++)
{
var origpprtargetid =
pprtargetnodes.item(i).attributes(0).text;
var tructargetid;
var ind = origpprtargetid.indexOf("__xc");
if (ind > -1 )
{
tructargetid = origpprtargetid.substring(0,ind);
}
else
{
tructargetid = origpprtargetid;
}
var pprnode = root.selectNodes("//ppr[@target_id='"
+ tructargetid
+ "']");
if ((pprnode != null) && (pprnode != (void 0)))
{
try
{
var pprtext =
pprnode.item(0).childNodes.item(0).nodeTypedValue;
var newpprtext = pprtext.toString();
if ((pprtext.indexOf("span") > -1)
|| (pprtext.indexOf("div") > -1))
{
var re = new RegExp ('\\s*id\\s*=\\s*"'
+ origpprtargetid
+ '"\\s*', "gi");
//var re =new
RegExp('span\\s*id\\s*=\\s*"(.*?)"\\s*',"gi");
newpprtext = pprtext.replace(re,' id="'
+ origpprtargetid
+ '_ppr_" ');
// newpprtext = pprtext.replace(re,'span
id="$1_ppr_" ');
}
// alert(origpprtargetid + " " + tructargetid + " "
// + i + " " +newpprtext);
eval("window['"
+ origpprtargetid
+
"'].innerHTML=newpprtext+'<script>'+pprscript+'</script>'");
}
catch(e)
{
// alert("exception here" + e.message);
}
}
}
}
catch (e)
{
var elem = form.elements["partial"];
elem.value="";
form.target="_self";
form.submit();
return doSubmit;
}
finally
{
xmlHttp = null;
xmlDoc = null;
responseString = null;
root = null;
}
}
}
else
{
form.target="_self";
form.submit();
return doSubmit;
}
}
else // ! (_agent.isPIE)
{
form.submit();
if (_blockOnEverySubmit)
_pprStartBlocking(window);
}
Can this be fixed any sooner ?
Regards,
Piyush