This follows on from a problem I had a few days ago, which I thought was my stupidity (not fully understanding were to specify the line endings in a document)
Ok I have little oddity with an action and again I am hoping some one has come across this before.
At the moment the Scriptmaker action places the content of a large field at fwBeforeStartHTML and then removes the all the Freeway generated HTML. so we end up with a clean script doc.
The problem I am getting is if I type some script into this field and use a carriage return within the scripts I type or if I copy and paste, then the document line endings which I have specified in the document (which were set to UNIX) are ignored and Classic Mac (CR) are used instead…
Does any one know why? Is this a fault with the large field? or the way I am using it as a before HTML
Oddly enough if I don’t add the carriage returns then its fine. I have viewed the page with “view invisibles on” and this is an example of what I get:
If I type in this “one liner” like below
example text
Then the output viewed with invisible on within text wrangler is… (note the line ending)
example text¬
¬
text wranger also indicates this is uses: UNIX LF
If I then close the document down from Text Wranger
ad go back to the Freeway Doc add a carriage return within the large text field publish and view the output again within Text Wrangler then I am getting this (note the second line ending now)
Hi Max,
Have you tried forcing the line endings to the page setting?
For example;
outputcode.fwConvertLineEndings = true;
assuming that outputcode contains the markup from your fwBigPrompt
input.
I think this should do the trick. If not i’ve looped through the code
before and written it out one line at a time using fwAddRawln which
will automatically add the correct line ending based on the setting
for the site.
Regards,
Tim.
Hi Tim
Thanks for pointing me in the right direction and with a possible solution… plus sorry for now being slow on the uptake, but did you get the reference to
outputcode.fwConvertLineEndings = true;
from the actions manual? or is it mentioned somewhere else in a release note, or is it even used somewhere so I can see it in use etc…
cheers again and all the best
Hi Max,
I’d love to point you to the documentation for this, but, AFAIK it
isn’t documented anywhere.
Have a root through the Blogger Posts action (part of the Blogger
Template Suite) and you’ll find;
// Add the item contents
var itemContents = fwMarkups[“posts”];
itemContents.fwConvertLineEndings = true;
I’ve taken to looking closely at actions that come from Softpress as
they sometimes reveal things that aren’t in the documentation yet.
Regards,
Tim.
On 14 Oct 2009, at 12:59, max wrote:
Hi Tim
Thanks for pointing me in the right direction and with a possible
solution… plus sorry for now being slow on the uptake, but did
you get the reference to
outputcode.fwConvertLineEndings = true;
from the actions manual? or is it mentioned somewhere else in a
release note, or is it even used somewhere so I can see it in use
etc…
cheers again and all the best
I’m fairly certain that fwConvertLineEndings will only convert the
endings of fwMarkup, not a string. You will have to do what Walter
resorted to doing when he noticed this and write the text out to the
new file line by line instead of en masse. To do this you’ll need to
split the string up using line endings as separators and write each
entry in the array (using the Sting.split(separator) function, where
separator can be a regex such as /r/) to file using the file.fwWriteln
() function.
Hope this helps,
Joe
On 14 Oct 2009, at 13:40, Tim Plumb wrote:
Hi Max,
I’d love to point you to the documentation for this, but, AFAIK it
isn’t documented anywhere.
Have a root through the Blogger Posts action (part of the Blogger
Template Suite) and you’ll find;
// Add the item contents
var itemContents = fwMarkups[“posts”];
itemContents.fwConvertLineEndings = true;
I’ve taken to looking closely at actions that come from Softpress as
they sometimes reveal things that aren’t in the documentation yet.
Regards,
Tim.
On 14 Oct 2009, at 12:59, max wrote:
Hi Tim
Thanks for pointing me in the right direction and with a possible
solution… plus sorry for now being slow on the uptake, but did
you get the reference to
outputcode.fwConvertLineEndings = true;
from the actions manual? or is it mentioned somewhere else in a
release note, or is it even used somewhere so I can see it in use
etc…
cheers again and all the best
After a bit of messing around and using the “outputcode.fwConvertLineEndings = true;” on markup
it still didn’t work…boo hoo… TextWrangler was still indicated that the file was a doc with Classic Mac (CR) endings.
So I went back to what I originally had and after a bit of testing its turing out that with the setup I had the line endings problems only occurred when I used the fwBeforeStartHTML()
function fwBeforeStartHTML(){
var HTMLTag = fwDocument.fwTags;
HTMLTag.fwAddRaw(fwParameters["Scriptattributes"]);
Now this adds the content of the field right at the beginning of the document before anything else is written (I have basically jumped in prior to anything being physically written by Freeway) which is what I wanted. I then proceed to delete everything else leaving me with a clean document with just my script. The problem is that the document produced does not use the document line ending which I specified in the general overall document setting.
If on the other-hand I inject the contents of that field at fwAfterStartHTML then the document produced does use the UNIX (LF) settings, which is great apart for one problem.
Because I have now specified that the contents will be written after the Start, I now have a carriage return that is left by the !DOCTYPE being deleted. So in other words there is a carriage return before my script, and for the life of me I cant work out how to get rid of it, and I do need to remove it to allow certain scripts to work correctly… can anyone shed any light on how I may be able to target that first “¬” carriage return.
Hi Max,
Jump in at the end of the publishing cycle, not the beginning, because
other actions may be trying to add to the page. If you process the
page too early on then other actions will either add to your page code
or most likely throw and error.
Something like this will eliminate all of the code on the page and
inject your markup in it’s place;
var allTags = fwDocument.fwTags.fwFindAllContent();
for (i in allTags) {
allTags[i].fwDelete();
}
var dummy = allTags[0].fwAddEnclosing(“”, false);
var mynewcode = dummy.fwAddRaw(mycustomcode);
Regards,
Tim.
On 15 Oct 2009, at 16:35, max wrote:
Unfortunately I am going around in circles here
After a bit of messing around and using the
“outputcode.fwConvertLineEndings = true;” on markup
it still didn’t work…boo hoo… TextWrangler was still indicated
that the file was a doc with Classic Mac (CR) endings.
So I went back to what I originally had and after a bit of testing
its turing out that with the setup I had the line endings problems
only occurred when I used the fwBeforeStartHTML()
function fwBeforeStartHTML(){
var HTMLTag = fwDocument.fwTags;
HTMLTag.fwAddRaw(fwParameters["Scriptattributes"]);
Now this adds the content of the field right at the beginning of the
document before anything else is written (I have basically jumped in
prior to anything being physically written by Freeway) which is what
I wanted. I then proceed to delete everything else leaving me with a
clean document with just my script. The problem is that the document
produced does not use the document line ending which I specified in
the general overall document setting.
If on the other-hand I inject the contents of that field at
fwAfterStartHTML then the document produced does use the UNIX (LF)
settings, which is great apart for one problem.
Because I have now specified that the contents will be written after
the Start, I now have a carriage return that is left by the !
DOCTYPE being deleted. So in other words there is a carriage return
before my script, and for the life of me I cant work out how to get
rid of it, and I do need to remove it to allow certain scripts to
work correctly… can anyone shed any light on how I may be able to
target that first “¬” carriage return.
Hi Tim cheers for your alternative and even though it works… it comes up with the same problem as my version… once everything on the page is removed (apart from the custom code ) then text wrangler indicates that the published file is still a Mac CR doc.
I am at the point of giving upon it now as I am begging to think this is something that cant be tackled via the action.
Anyway thanks everyone for all the input and all the best… max
