erlangweb-users

Re: [Erlangweb-users] patches => Re: Erlang Web 1.3RC1 is ready

[Michal P. <mic...@er...>]

That is a bug indeed. One of our major goals is to plug off
the xmerl as a template processor (it is slow, heavy and has
oversized structures): the first step was to remove its dependency
from the wtype's (the modules responsible for formatting and 
validation). 

Everything works well as long as wtype returns a plain text (type of 
the returning structure is 'text', not 'cdata'). Unfortunately, there
is only one place where we actually break the convention and change 
the returning type: wtype_html. 

As a workaround I have prepared a little patch for wpart_include 
(the second place where the changes took place is wpart_lookup - 
it also uses 'format' attribute for changing the display of the 
data). A quick fix introduces a new attribute to wpart_include 
(wpart_lookup has it since 1.2.1): 'type'. 

In case 'type' is set to 'cdata' the data is rendered as it was
an HTML part of the document. Otherwise, all characters are printed
out (e.g. > is encoded to >).

The patch has been commited to the bitbucket's repository 
(changeset 70bc68ef8b93: 
http://bitbucket.org/etc/erlang-web/changeset/70bc68ef8b93/)

Thank you for pointing out the inconsistency.

----- "Michael McDaniel" <erl...@au...> wrote:

> I am happy to be able to contribute.  I installed 1.3RC1 on
>  http://trip.autosys.us and found that a change in
>  lib/wparts-N/wpart_include.erl causes breakage of stylesheet
>  includes, e.g. using
> 
>   <wpart:include file="templates/trip/style.css" format="html" />
> 
>  causes style information to show up as plain text using 1.3RC1.
>  Using 1.2.1 and the style information would affect the page
>  style as desired.
> 
> 
>  Here is the change ...
> 
> 
> < is from wparts-1.2.1
> > is from wparts-1.3
> 
> 39c38,39
> <       wpartlib:format(#xmlText{value = Tpl}, E);      %% STYLIN'
> ---
> >       #xmlText{value = wpartlib:format(Tpl, E)};      %% PLAIN TEXT
> 
> 
> 
>  I did not make a patch because I do not know why the change was
>  made.  
> 
>  Is there some other recommended way of including a stylesheet ?
>  (for now, I have changed my local code so the includes work)
> 
> 
> 
> ~M

-- 
Michal Ptaszek
www.erlang-consulting.com

Re: [Erlangweb-users] patches => Re: Erlang Web 1.3RC1 is ready

[Ulf W. <ul...@wi...>]

2009/5/6 Michal Ptaszek <mic...@er...>:
> That is a bug indeed. One of our major goals is to plug off
> the xmerl as a template processor (it is slow, heavy and has
> oversized structures): the first step was to remove its dependency
> from the wtype's (the modules responsible for formatting and
> validation).

Just so you know, xmerl will very soon be released in a new version
that is much faster, and also supports a much leaner interface.

I assume this will happen in R13B-1.

If you look into xmerl in R13B, you will find some new building
blocks. They are not documented, and the new API is not yet
ready, but preliminary reports indicate that it will be roughly as
fast as erlsom, with the option to use the old interface.

BR,
Ulf W

Re: [Erlangweb-users] patches => Re: Erlang Web 1.3RC1 is ready

[Michael T. <mj...@gm...>]

Ulf Wiger wrote:
> 2009/5/6 Michal Ptaszek <mic...@er...>:
>   
>> That is a bug indeed. One of our major goals is to plug off
>> the xmerl as a template processor (it is slow, heavy and has
>> oversized structures): the first step was to remove its dependency
>> from the wtype's (the modules responsible for formatting and
>> validation).
>>     
>
> Just so you know, xmerl will very soon be released in a new version
> that is much faster, and also supports a much leaner interface.
>
> I assume this will happen in R13B-1.
>
> If you look into xmerl in R13B, you will find some new building
> blocks. They are not documented, and the new API is not yet
> ready, but preliminary reports indicate that it will be roughly as
> fast as erlsom, with the option to use the old interface.
>
> BR,
> Ulf W
>   
Do you know if the new xmerl will be faster than the ejabberd expat
interface?

Thanks,
Michael