Re: TransitionMLS scenario

Marcel van der Boom wrote:
> On 24 mrt 2008, at 11:00, marcinmilanxaraya.com wrote:
> 
> [re-arranged a bit]
> 
> 1. what do we do about text nodes we don't want
translated, such as  
> javascript, css or the stuff inside the <pre>
tag?
> 2. what children do we allow for the xar:set tag?
> 3. where should #...# syntax be allowed?
> 
> First, these questions are generic, not specific for
the scenario,  right?
> 
> Ad. 1.
> In the proposal on MLS changes i wrote a while ago, i
proposed the  
> xml:lang attribute for this.
> A good read on this attribute is here: http://www.opent
ag.com/xfaq_lang.htm
> 
> Of course the definition "this content is in this
language" and "dont  
> translate this" is not the same statement in
general. The first is the  
> statement in XML by the xml:lang attribute. The second
is how the XML  
> handlers "reacts" on this statement (in our
case, BL2 compiler)

Also, language and locale do not necessarily correlate.  I
have no 
objection to using xml:lang to switch languages, but I'm
pretty sure 
we'll have to implement our own locale switching.

> 
> Ad. 2
> The xar:set tag has to be redesigned completely. It is
now a fallback  
> to get anything done in a template we can not express
neatly in our  
> templating language. The compiled variety expects
anything inside the  
> tag to evaluate to "Something assignable"
(PHP wise).  "Something  
> assignable" in XML has a different meaning than in
PHP. We should  solve 
> this bit step by step imo. Until we reach some
threshold where  the BL 
> language is more expressive, xar:set will be around i
think.  This is on 
> many levels related to the third question.

What are the steps, as you see them?  xar:set is arguably
the most 
versatile tag we have, but it is prone to exploitation. 
Even if 
"assignable" has different meanings in XML and
PHP, do we still need to 
maintain a point in the process where data/expressions
"jump" this fence?

> 
> Ad. 3
> The #...# syntax is used as an 'escape' mechanism to
formulate  
> expression in the XML where we dont have a XML
mechanism to do this  for 
> us. As such, the question where it is allowed is fuzzy,
because it  aint 
> treated as part of the XML. Anything we come up with we
need to  
> implement ourselves. Again i think we should take this
one at a time.
> 
> #$test# is already equivalent to <xar:var
name="test"/>
> 
> the latter is treated integrally in the BL compiler,
the first needs  
> preprocessing hack to make it XML first ( in this case
creating a  
> processing instruction with the php target)
> 
> For me the obvious long term route is first to offer
the data to  
> templates as an XML nodeset/fragment instead of a PHP
array and then  
> use XPath as the expression language to query and
manipulate that  data. 
> If that route is acceptable for others, i dunno. Going
that  route 
> solves the '#' symbol discussion which every now and
then seems  to pop 
> up. It also solves the 'domain mixing' problems we have
 introduced (see 
> xar:set, xar:ml expresssions xar:if conditions etc.) 
It creates a while 
> new set of problems though.
> 
> I've done some work on the first part (offering tpl
data as XML  
> nodeset) but this is still experimental. XML in general
and XPath in  
> particular support is much better now than at the time
BL1 saw the  light.
> 

XPath is an interesting direction that make sense
conceptually.  It is 
feature-rich, but I doubt it can completely replace PHP for
us.

Getting data out of a tpldata nodeset seems straighforward,
but what 
about putting new data into it (ie, xar:set)?

Future cases involve our output stream being manipulated by
XPath after 
xar has delivered it, how do we allow these expressions to
pass through 
BL (the same issues we've had with <!-- --> and are
soon going to have 
with <![CDATA[ ]]>)?

Will XPath allow us to discard the $tpl:foo ugliness at the
page 
template level?

Scope: will each template's data nodeset have its own root,
or will all 
data become part of a universal nodeset?

I for one will probably need to see a template (even a
theoretically 
functional mockup) that uses XPath to fully understand how
the 
expressions and functions would be used.
_______________________________________________
Xaraya_devel mailing list
Xaraya_develxaraya.com
http:
//xaraya.com/mailman/listinfo/xaraya_devel

On 26 mrt 2008, at 19:35, Marty Vance wrote:

> Also, language and locale do not necessarily
correlate.
Well, they do correlate, but are two different things.
Language is a  
subset of locale.

>  I have no
> objection to using xml:lang to switch languages, but
I'm pretty sure
> we'll have to implement our own locale switching.
Agreed. Locale switching is much more complex. I'm
suppressing it in  
my head. It would be awesome already if we could seamlessly
switch  
language only, in its broadest sense. I havent seen many
real requests  
for in-page complete locale switching, nor do i have a good 

understanding what it would be like to switch a complete
locale.


> What are the steps, as you see them?  xar:set is
arguably the most
> versatile tag we have, but it is prone to exploitation.
 Even if
> "assignable" has different meanings in XML
and PHP, do we still need  
> to
> maintain a point in the process where data/expressions
"jump" this  
> fence?

As some examples of initial steps i see:
- ironing out all the known inconsistencies, making sure we
dont  
introduce new ones
- making the use of xar:var more consistent within the xml
framework  
(this has already started)
- solving part of the expression problems, perhaps
temporarily,  
allowing to set/create data-structures without going into
php mode
(the latter may just be rewriting some xar:set's into
GUI/API files,  
dunno really)
- re-evaluating xar:var/xar:mlvar/xar:set after we have
changed MLS  
concept.
In general, most of the work involved is good specs. I think
the code  
as such is not that hard to write, relatively speaking.


> XPath is an interesting direction that make sense
conceptually.  It is
> feature-rich, but I doubt it can completely replace PHP
for us.

I think it can, if only because it is possible to 'extend'
xpath with  
functions, just like we have expanded the xslt vocabulary a
little bit  
for the BL2 compiler. Theoretically if we 'map' many
functions from  
PHP to the XPath domain (we should not do this however).
Given the  
extendable functions and the logical expression power XPath
already  
has, i dont think there are constructs in templates which
need more  
expressive power than that.


> Getting data out of a tpldata nodeset seems
straighforward, but what
> about putting new data into it (ie, xar:set)?
The principle of encoding, delivering and setting data in
the template  
scope doesn't really change, just the vehicle for it.

Now we encode data as a (nested) array tplData, with XPath
we will  
encode it as a XML fragment in a certain defined format
(dtd).

Getting a variable now is using the PHP way of 'adressing'
an element  
in this array, where the contents of the array can be atomic
(string,  
number, bool, etc.) or structured (array or object). Given
the tpl  
data as XML fragment, the 'adressing' to get to a node(set)
is XPath.  
Elements can be atomic (textnodes) or structured
(nodesets).

Setting a variable is now injecting a new element in the
tplData array  
and making sure it has the right address. One of the
problems we have  
now is that it's nigh impossible to create structured
elements in a  
way which is acceptable, meaning that we still play nice in
the PHP  
and XML world. Setting a variable with tplData as XML
fragment is  
inserting a node(set) into the runtime XML fragment. This
can be done  
by an XSL operation joining the two nodesets, or a DOM
manipulation.

The vehicle however is important here. In the current
situation we  
constantly have to take 2 worlds into account. PHP and XML
(or worse:  
pseudo XML).  By making sure that the canvas (template), the
tpldata  
and the adressing are all XML (and preferably standard) we
make our  
lifes easier, from a coding perspective.

Sound all nice to me, but we still have to do it 

> Future cases involve our output stream being
manipulated by XPath  
> after
> xar has delivered it, how do we allow these expressions
to pass  
> through
> BL (the same issues we've had with <!-- --> and
are soon going to have
> with <![CDATA[ ]]>)?
Not sure what you mean here. The output stream manipulated
by XPath?


> Will XPath allow us to discard the $tpl:foo ugliness at
the page
> template level?
Not sure what you mean here either. $tpl:foo is ugly in page
templates  
because of the notation or the fact that it is there at
all?


> Scope: will each template's data nodeset have its own
root, or will  
> all
> data become part of a universal nodeset?
A template as such is 'scoped', that is, it is used within a
certain  
context. The template as such only requires a 'minimum'
nodeset to be  
present at that scope so it's data is available. The nodeset
may  
contain more than that if needed by the context. I envision
a nodeset  
to be single rooted for a certain code-path.  This is
however more a  
gut feeling than anything else.


> I for one will probably need to see a template (even a
theoretically
> functional mockup) that uses XPath to fully understand
how the
> expressions and functions would be used.
Yes, that is a good idea. I did such a mock up in the past.
I think i  
have that somewhere still. When time permits, will look that
up and  
post somewhere.

marcel

-- 
Marcel van der Boom -- http://hsdev.com/mvdb.vcf
HS-Development BV   -- http://www.hsdev.com
So! webapplicaties  -- http://make-it-so.info



_______________________________________________
Xaraya_devel mailing list
Xaraya_develxaraya.com
http:
//xaraya.com/mailman/listinfo/xaraya_devel