<br/>

no xml expert... i can do as far as this def asXhtml(s: String) =

{s split "\\n" flatMap (t => List(Text(t),
)) dropRight(1)}

but the
still get expanded to
best, -sciss- On 24 Apr 2011, at 08:02, Vlad Patryshev wrote: > It's been a while, but I have a feeling there's no solution yet. Or is there? > Inserting
into your xhtml output, is it doable while passing around Node? > > Namely, I have Text("first line")
Text("second line")
- will it work? Does not look like it will. > > scala>

this is a message
and this is another

> res1: scala.xml.Elem =

this is a message
and this is another

> > ......... > > This one at least compiles: > > def asXhtml(s: String): Array[Elem] = s split "\\n" map {x: String =>
{ x } } > > > Thanks, > -Vlad

is short for
, so Scala is quite right to expand it. In fact, it's not actually expanding anything, just not carrying any special logic about the short form. In this way, it is exactly in line with other XML representations like the DOM, SAX events, etc. Feature, not bug. :-) Daniel On Apr 24, 2011, at 2:02 AM, Vlad Patryshev wrote: > It's been a while, but I have a feeling there's no solution yet. Or is there? > Inserting
into your xhtml output, is it doable while passing around Node? > > Namely, I have Text("first line")
Text("second line")
- will it work? Does not look like it will. > > scala>

this is a message
and this is another

> res1: scala.xml.Elem =

this is a message
and this is another

> > ......... > > This one at least compiles: > > def asXhtml(s: String): Array[Elem] = s split "\\n" map {x: String =>
{ x } } > > > Thanks, > -Vlad

I would like it to be shortened as well. XML is bloated enough as it is. It's much easier to read in shortened format as well. On Apr 24, 2011, at 8:55 AM, Daniel Spiewak wrote: >
is short for
, so Scala is quite right to expand it. In fact, it's not actually expanding anything, just not carrying any special logic about the short form. In this way, it is exactly in line with other XML representations like the DOM, SAX events, etc. > > Feature, not bug. :-) > > Daniel > > On Apr 24, 2011, at 2:02 AM, Vlad Patryshev wrote: > >> It's been a while, but I have a feeling there's no solution yet. Or is there? >> Inserting
into your xhtml output, is it doable while passing around Node? >> >> Namely, I have Text("first line")
Text("second line")
- will it work? Does not look like it will. >> >> scala>

this is a message
and this is another

>> res1: scala.xml.Elem =

this is a message
and this is another

>> >> ......... >> >> This one at least compiles: >> >> def asXhtml(s: String): Array[Elem] = s split "\\n" map {x: String =>
{ x } } >> >> >> Thanks, >> -Vlad

On Sunday April 24 2011, Jori Jovanovich wrote: > I would like it to be shortened as well. XML is bloated enough as it > is. It's much easier to read in shortened format as well. Pipe your XML through this for viewing: sed -r -e 's;<([^> ]+)([^>]*)>;;g' % echo '
' |sed -r -e 's;<([^> ]+)([^>]*)>;<\1\2/>;g'
% echo '
' |sed -r -e 's;<([^> ]+)([^>]*)>;<\1\2/>;g'
Randall Schulz

scala> xml.Utility.toXML(

this is a message
and this is another

, minimizeTags = true).toString res1: java.lang.String =

this is a message
and this is another

On Sun, Apr 24, 2011 at 04:02, Vlad Patryshev wrote: > It's been a while, but I have a feeling there's no solution yet. Or is > there? > Inserting
into your xhtml output, is it doable while passing around > Node? > >  Namely, I have Text("first line")
Text("second line")
- will it > work? Does not look like it will. > > scala>

this is a message
and this is another

> res1: scala.xml.Elem =

this is a message
and this is another

> > ......... > > This one at least compiles: > >   def asXhtml(s: String): Array[Elem] = s split "\\n" map {x: String => >
{ x } } > > > Thanks, > -Vlad >

On 04/24/2011 05:55 PM, Daniel Spiewak wrote: >
is short for
, so Scala is quite right to expand it. In fact, it's not actually expanding anything, just not carrying any special logic about the short form. In this way, it is exactly in line with other XML representations like the DOM, SAX events, etc. > > Feature, not bug. :-) Bug, not feature. There was a long discussion, but you seem like hoping it's forgotten. Long form assumes empty text node inside, it's parsed so by most DOM libs. Firefox inserts extra newline with this long form. Arbitrary extra node cannot be feature. Nobody in web uses this "feature". I personally asked just to preserve the original form as it was typed by programmer - whether it's short or long. Pity there's no change after so long time. I still have to keep fixScalaSerializedXML function in lib.web to make Firefox feel well, and possibly I'll be forced to extend it in the future because you expand everything, not only
- you produce , and so on. Lame, extremely lame. Pity, guys.

By the way, do I still have to create CDATA sections manually
(http://www.scala-lang.org/node/6180), or you at last shifted from
theory to practice and made it compatible with the way ALL browsers
handle it?

I forgot about the empty text node bit.  Thanks for reminding me!  I'll make sure this case is handled correctly in Anti-XML…

Daniel

On Sun, Apr 24, 2011 at 2:21 PM, Dmitry Grigoriev <mail@dimgel.ru> wrote:

On 04/24/2011 05:55 PM, Daniel Spiewak wrote:
> <br/> is short for <br></br>, so Scala is quite right to expand it.  In fact, it's not actually expanding anything, just not carrying any special logic about the short form.  In this way, it is exactly in line with other XML representations like the DOM, SAX events, etc.
>
> Feature, not bug.  :-)

Bug, not feature. There was a long discussion, but you seem like hoping
it's forgotten. Long form assumes empty text node inside, it's parsed so
by most DOM libs. Firefox inserts extra newline with this long form.
Arbitrary extra node cannot be feature. Nobody in web uses this
"feature". I personally asked just to preserve the original form as it
was typed by programmer - whether it's short or long. Pity there's no
change after so long time. I still have to keep fixScalaSerializedXML
function in lib.web to make Firefox feel well, and possibly I'll be
forced to extend it in the future because you expand everything, not
only <br/> - you produce <meta></meta>, <img></img> and so on. Lame,
extremely lame. Pity, guys.

--
Cheers,
dimgel

http://dimgel.ru/lib.web
Thin, stateless, strictly typed Scala web framework.

Patches welcome.

On Apr 24, 2011 3:21 PM, "Dmitry Grigoriev" <mail@dimgel.ru> wrote:
> On 04/24/2011 05:55 PM, Daniel Spiewak wrote:
>> <br/> is short for <br></br>, so Scala is quite right to expand it. In fact, it's not actually expanding anything, just not carrying any special logic about the short form. In this way, it is exactly in line with other XML representations like the DOM, SAX events, etc.
>>
>> Feature, not bug. :-)
>
> Bug, not feature. There was a long discussion, but you seem like hoping
> it's forgotten. Long form assumes empty text node inside, it's parsed so
> by most DOM libs. Firefox inserts extra newline with this long form.
> Arbitrary extra node cannot be feature. Nobody in web uses this
> "feature". I personally asked just to preserve the original form as it
> was typed by programmer - whether it's short or long. Pity there's no
> change after so long time. I still have to keep fixScalaSerializedXML
> function in lib.web to make Firefox feel well, and possibly I'll be
> forced to extend it in the future because you expand everything, not
> only <br/> - you produce <meta></meta>, <img></img> and so on. Lame,
> extremely lame. Pity, guys.
>
> --
> Cheers,
> dimgel
>
> http://dimgel.ru/lib.web
> Thin, stateless, strictly typed Scala web framework.
>

On 24/04/2011 21:21, Dmitry Grigoriev wrote:
> Bug, not feature.

I agree here. I see no point/usefulness to expand this.

> I personally asked just to preserve the original form as it
> was typed by programmer - whether it's short or long.

Good idea. There is a case where we need the empty node form:

On 24/04/2011 19:21, Daniel Sobral wrote: > scala> xml.Utility.toXML(

this is a message
and this is > another

, minimizeTags = true).toString > res1: java.lang.String =

this is a message
and this is another

Now, the annoying think is the space before the closing slash. As far as I know, this form was created because Netscape Navigator/Communicator didn't understand XHTML unless this space is added. I guess there aren't so much such browsers around today, so we can get rid of this form. Which is totally useless in pure XML, anyway. Unless I am missing something?

On Sun, Apr 24, 2011 at 9:21 PM, Dmitry Grigoriev wrote: > On 04/24/2011 05:55 PM, Daniel Spiewak wrote: >>
is short for
, so Scala is quite right to expand it.  In fact, it's not actually expanding anything, just not carrying any special logic about the short form.  In this way, it is exactly in line with other XML representations like the DOM, SAX events, etc. >> >> Feature, not bug.  :-) > > Bug, not feature. There was a long discussion, but you seem like hoping > it's forgotten. Long form assumes empty text node inside, it's parsed so > by most DOM libs. Firefox inserts extra newline with this long form. > Arbitrary extra node cannot be feature. Nobody in web uses this > "feature". I personally asked just to preserve the original form as it > was typed by programmer - whether it's short or long. Pity there's no > change after so long time. I still have to keep fixScalaSerializedXML > function in lib.web to make Firefox feel well, and possibly I'll be > forced to extend it in the future because you expand everything, not > only
- you produce , and so on. Lame, > extremely lame. Pity, guys. > > -- > Cheers, > dimgel > > http://dimgel.ru/lib.web > Thin, stateless, strictly typed Scala web framework. > > Definite usability frustration to the extent that if you put in
you'd expect it to stay like that, but not a bug. The spec is clear on this is identical to (http://www.w3.org/TR/2008/REC-xml-20081126/#sec-starttags). If software treats them differently its broke with respect to xml. That said, there is lots of broke software out there. For Scales XML I'm still very much undecided, because saying all should become on marshalling seems equally broke to me, but I have a grave disliking for adding a data member to Elem or adding a new EmptyElemInPreference class or trait just to control serialisation options even though it seems the easiest way. I'm also on the fence regarding serialisation order for attributes, alot of people want that, but it too is broke with regards to the spec.

On Mon, Apr 25, 2011 at 12:40 PM, Philippe Lhoste wrote: > On 24/04/2011 19:21, Daniel Sobral wrote: >> >> scala>  xml.Utility.toXML(

this is a message
and this is >> another

, minimizeTags = true).toString >> res1: java.lang.String =

this is a message
and this is another

> > Now, the annoying think is the space before the closing slash. As far as I > know, this form was created because Netscape Navigator/Communicator didn't > understand XHTML unless this space is added. > I guess there aren't so much such browsers around today, so we can get rid > of this form. Which is totally useless in pure XML, anyway. > Unless I am missing something? > > -- > Philippe Lhoste

For Scales XML I'm still very much undecided, because saying all
<el></el> should become <el/> on marshalling seems equally broke to
me, but I have a grave disliking for adding a data member to Elem or
adding a new EmptyElemInPreference class or trait just to control
serialisation options even though it seems the easiest way.

My take on this for Anti-XML: if you want the <el></el> form, then you need to create your element like so: Elem(None, "el", Map(), Group(Text(""))).  So in other words, the empty Text node needs to be explicit.  Whether or not a compiler plugin can convince the XML literals to generate this is another question.

I'm also on the fence regarding serialisation order for attributes,
alot of people want that, but it too is broke with regards to the
spec.

I'm going to actually preserve the order in the attributes data structure.  Annoying, but I can't think of a better way.  At least it won't be serialization-specific

Daniel

On 04/25/2011 02:56 PM, Chris Twiner wrote: > Definite usability frustration to the extent that if you put in
> you'd expect it to stay like that, but not a bug. The spec is clear > on this is identical to > (http://www.w3.org/TR/2008/REC-xml-20081126/#sec-starttags). If > software treats them differently its broke with respect to xml. That > said, there is lots of broke software out there. Once again: cling to practice, not theory. If EVERYONE violates standard, such standart must be thrown away. Where's that old and theoretically-good 7 layers OSI model, m?

On Mon, Apr 25, 2011 at 10:26 AM, Dmitry Grigoriev <mail@dimgel.ru> wrote:

Once again: cling to practice, not theory. If EVERYONE violates
standard, such standart must be thrown away. Where's that old and
theoretically-good 7 layers OSI model, m?

That's over-simplified.  The reality is more complex: there are two *different* standards and practices in play here, and they fundamentally contradict each other.  Scala is largely focused on XML, and XML *is* very consistent and well-defined, and used by a huge number of different systems.
Unfortunately, XHTML in practice still doesn't play nicely by XML rules, even though that was the entire point of creating XHTML in the first place.  So it's a weird exception case.  And yes, theory and practice diverge -- but the practice of XML and the practice of XHTML are not the same...

On 04/25/2011 06:30 PM, Justin du coeur wrote:
> Unfortunately, XHTML in practice still doesn't play nicely by XML rules,
> even though that was the entire point of creating XHTML in the first
> place. So it's a weird exception case. And yes, theory and practice
> diverge -- but the practice of XML and the practice of XHTML are not the
> same...

Interesting, thanks for explanation.

On Mon, Apr 25, 2011 at 10:30 AM, Justin du coeur <jducoeur@gmail.com> wrote:

On Mon, Apr 25, 2011 at 10:26 AM, Dmitry Grigoriev <mail@dimgel.ru> wrote:

Once again: cling to practice, not theory. If EVERYONE violates
standard, such standart must be thrown away. Where's that old and
theoretically-good 7 layers OSI model, m?

That's over-simplified.  The reality is more complex: there are two *different* standards and practices in play here, and they fundamentally contradict each other.  Scala is largely focused on XML, and XML *is* very consistent and well-defined, and used by a huge number of different systems.
Unfortunately, XHTML in practice still doesn't play nicely by XML rules, even though that was the entire point of creating XHTML in the first place.  So it's a weird exception case.  And yes, theory and practice diverge -- but the practice of XML and the practice of XHTML are not the same...

I'm sure that discrepancies like these pushed Lift to supporting HTML5 (well, that and the fact that XHTML didn't get the traction that people expected).

--
Jim Powers

On 04/25/2011 02:37 PM, Philippe Lhoste wrote:
>> I personally asked just to preserve the original form as it
>> was typed by programmer - whether it's short or long.
>
> Good idea. There is a case where we need the empty node form:
>
>

+1, this is where some browsers don't take short tag correctly.

So, if we are less formalistic and just keep it as encountered: both <br/> and <script src=".."></script> as they are...
Thanks,
-Vlad


On Tue, Apr 26, 2011 at 10:24 AM, Dmitry Grigoriev <mail@dimgel.ru> wrote:

On 04/25/2011 02:37 PM, Philippe Lhoste wrote:
>> I personally asked just to preserve the original form as it
>> was typed by programmer - whether it's short or long.
>
> Good idea. There is a case where we need the empty node form:
> <script src="some path"></script>
>

+1, this is where some browsers don't take short tag correctly.

--
Cheers,
dimgel

http://dimgel.ru/lib.web
Thin, stateless, strictly typed Scala web framework.