Re: [Pharo-users] Alternate browser

[kilon alios]

"In my image, I have 144 such extensions taking on average 9 lines of code."

Impressive then apparently GT tools goes exactly the direction I wanted. I
was aware of Glamour but to be frank I have not seen anyone else use it but
you guys so I was kinda sceptical about it and did not took it very
seriously. I was not aware that GT tools were built on top of Glamour and
this certainly gives it more credit, I thought it was merely for making
custom browsers looks like its a lot more than that. Thank you Tudor you
gave me a lot of to read.

I definetly when to develop my tools and libraries in sync to the direction
Pharo is going so I can take advantage of the existing code and not
reinvent the wheel. So now I will sit down and study all these technologies
and see how I can utilise them better in my workflow. Thank you for you
hard work and taking the time explaining.

On Tue, Dec 2, 2014 at 12:29 AM, Sven Van Caekenberghe  wrote:

>
> > On 01 Dec 2014, at 23:06, Tudor Girba  wrote:
> >
> > Glamour is an engine by itself, but for the inspector you mainly need
> the presentations, which are essentially widgets that can be parameterized
> through blocks. A custom presentation like this typically requires one
> method. If you want to get examples of how to apply it for the inspector,
> you can use the inspector to answer that question, as described here:
> > http://www.humane-assessment.com/blog/managing-gtinspector-extensions/
>
> Yes, yes, very nice.
>

Re: [Pharo-users] Alternate browser

[Tudor Girba]

Thanks for the kind words, Kilon.

Please feel free to ask questions.

Cheers,
Doru



On Tue, Dec 2, 2014 at 11:29 AM, kilon alios  wrote:

> "In my image, I have 144 such extensions taking on average 9 lines of
> code."
>
> Impressive then apparently GT tools goes exactly the direction I wanted. I
> was aware of Glamour but to be frank I have not seen anyone else use it but
> you guys so I was kinda sceptical about it and did not took it very
> seriously. I was not aware that GT tools were built on top of Glamour and
> this certainly gives it more credit, I thought it was merely for making
> custom browsers looks like its a lot more than that. Thank you Tudor you
> gave me a lot of to read.
>
> I definetly when to develop my tools and libraries in sync to the
> direction Pharo is going so I can take advantage of the existing code and
> not reinvent the wheel. So now I will sit down and study all these
> technologies and see how I can utilise them better in my workflow. Thank
> you for you hard work and taking the time explaining.
>
> On Tue, Dec 2, 2014 at 12:29 AM, Sven Van Caekenberghe 
> wrote:
>
>>
>> > On 01 Dec 2014, at 23:06, Tudor Girba  wrote:
>> >
>> > Glamour is an engine by itself, but for the inspector you mainly need
>> the presentations, which are essentially widgets that can be parameterized
>> through blocks. A custom presentation like this typically requires one
>> method. If you want to get examples of how to apply it for the inspector,
>> you can use the inspector to answer that question, as described here:
>> > http://www.humane-assessment.com/blog/managing-gtinspector-extensions/
>>
>> Yes, yes, very nice.
>>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] Alternate browser

[Hilaire]

Are you running your web service on a Linux box?
If so mail me privately to hila...@drgeo.eu

Hilaire

Le 01/12/2014 23:07, Tudor Girba a écrit :
> Indeed.
> 
> Can anyone help me with doing this?
> 
> Doru
> 
> On Mon, Dec 1, 2014 at 9:36 PM, Hilaire
>  > wrote:
> 
> Le 01/12/2014 15:09, Tudor Girba a écrit :
> >
> > Sorry for the trouble. I will try to migrate my websites to a more
> > stable technology :(.
> >
> 
> Not perfect, but you can set a cron to restart it daily.
> 
> Hilaire
> 
> --
> Dr. Geo - http://drgeo.eu
> iStoa - http://istoa.drgeo.eu
> 
> 
> 
> 
> 
> -- 
> www.tudorgirba.com 
> 
> "Every thing has its own flow"


-- 
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu

[Pharo-users] Umlauts in ZnUrl

[Udo Schneider]

All,

What's the expected behavior with non-ASCII characters in URLs. Let's 
say I want to access a file named "äöü.txt" - My assumption was that 
Zinc takes care of the UTF-8 -> 7bit (ASCII) -> Escape encoding. But 
there is either something I don't understand or some manual steps I'm 
missing.


The "straightforward" way doesn't work:
'http://myhost/path/with/umlaut/äöü.txt' asUrl. 
"ZnCharacterEncodingError: ASCII character expected"


Although the actual encoding seems to be able to handle it (ignoring the 
escapes slashes for the moment:

'http://myhost/path/with/umlaut/äöü.txt' urlEncoded.
"'http%3A%2F%2Fmyhost%2Fpath%2Fwith%2Fumlaut%2F%C3%A4%C3%B6%C3%BC.txt'"

Creating a URL from already escaped characters works as well:
'http://myhost/path/with/umlaut/%C3%A4%C3%B6%C3%BC.txt' asUrl.
"http://myhost/path/with/umlaut/%C3%A4%C3%B6%C3%BC.txt";

As does the decoding of such an URL:
'http://myhost/path/with/umlaut/%C3%A4%C3%B6%C3%BC.txt' urlDecoded.
"'http://myhost/path/with/umlaut/äöü.txt'"

At them moment I'm manually encoding UTF-8 characters in paths segments 
before trying to build the URL. But is this the correct way?


Best Regards,

Udo

Re: [Pharo-users] Umlauts in ZnUrl

[Sven Van Caekenberghe]

Hi Udo,

With a URL/URI there are two representations: the external one (the way they 
are written) and the internal one (what is really meant). ZnUrl follows this 
distinction.

When you say #asUrl (or #asZnUrl) you are actually parsing an external string 
representation. When doing so, percent decoding is done by ZnPercentEncoder. 
This class is strict, in that it does not allow non-safe, non-ascii characters 
in its input. AFAIK this is correct, but I can imagine a less strict 
interpretation (like the URL input box of a browser would allow). If you have a 
reading of the specs that says otherwise I would be very interested.

To save you from doing the encoding yourself, you have to construct the URL 
from its parts explicitly, like this:

ZnUrl new
  scheme: #http;
  host: 'myhost';
  addPathSegments: #('path' 'with' 'unlaut' 'äöü.txt');
  yourself.  

 => http://myhost/path/with/unlaut/%C3%A4%C3%B6%C3%BC.txt

Class comments and unit tests should help.

There is also this draft:

  http://stfx.eu/EnterprisePharo/Zinc-Encoding-Meta/

HTH,

Sven

PS: Incidentally, this does work

  'http://myhost/path/with/umlaut/äöü.txt' asFileReference asUrl.

because #asFileReference works differently.

> On 02 Dec 2014, at 23:32, Udo Schneider  wrote:
> 
> All,
> 
> What's the expected behavior with non-ASCII characters in URLs. Let's say I 
> want to access a file named "äöü.txt" - My assumption was that Zinc takes 
> care of the UTF-8 -> 7bit (ASCII) -> Escape encoding. But there is either 
> something I don't understand or some manual steps I'm missing.
> 
> The "straightforward" way doesn't work:
> 'http://myhost/path/with/umlaut/äöü.txt' asUrl. "ZnCharacterEncodingError: 
> ASCII character expected"
> 
> Although the actual encoding seems to be able to handle it (ignoring the 
> escapes slashes for the moment:
> 'http://myhost/path/with/umlaut/äöü.txt' urlEncoded.
> "'http%3A%2F%2Fmyhost%2Fpath%2Fwith%2Fumlaut%2F%C3%A4%C3%B6%C3%BC.txt'"
> 
> Creating a URL from already escaped characters works as well:
> 'http://myhost/path/with/umlaut/%C3%A4%C3%B6%C3%BC.txt' asUrl.
> "http://myhost/path/with/umlaut/%C3%A4%C3%B6%C3%BC.txt";
> 
> As does the decoding of such an URL:
> 'http://myhost/path/with/umlaut/%C3%A4%C3%B6%C3%BC.txt' urlDecoded.
> "'http://myhost/path/with/umlaut/äöü.txt'"
> 
> At them moment I'm manually encoding UTF-8 characters in paths segments 
> before trying to build the URL. But is this the correct way?
> 
> Best Regards,
> 
> Udo
> 
> 
> 

Re: [Pharo-users] Umlauts in ZnUrl

[Udo Schneider]

Hi Sven,

the distinction between external and internal representations was the 
part I didn't get - but it really makes sense.


Your approach with adding pathSegments works perfectly! I'm working with 
ZnClient though and reusing it for different requests. So I added the 
following two (three) methods to make my life easier:


ZnClient>>#addPathSegments: pathSegments
	"Modify the receiver's path by adding the elements of pathSegments at 
the end"


pathSegments do: [ :each | self addPathSegment: each ]

ZnClient>>#resetPath
self path: ''

I didn't want to overwrite #path: because I only need this for some 
special edge case.


ZnClient>>#webdavPath: path
self
resetPath;
addPathSegments: ($/ split: path)
BTW: The whole Zinc framework is a real pleasure to work with. Once I 
got used to thinking in terms of objects and not only strings I didn't 
want to look back :-)


CU,

Udo



On 03/12/14 00:02, Sven Van Caekenberghe wrote:

Hi Udo,

With a URL/URI there are two representations: the external one (the way they 
are written) and the internal one (what is really meant). ZnUrl follows this 
distinction.

When you say #asUrl (or #asZnUrl) you are actually parsing an external string 
representation. When doing so, percent decoding is done by ZnPercentEncoder. 
This class is strict, in that it does not allow non-safe, non-ascii characters 
in its input. AFAIK this is correct, but I can imagine a less strict 
interpretation (like the URL input box of a browser would allow). If you have a 
reading of the specs that says otherwise I would be very interested.

To save you from doing the encoding yourself, you have to construct the URL 
from its parts explicitly, like this:

ZnUrl new
   scheme: #http;
   host: 'myhost';
   addPathSegments: #('path' 'with' 'unlaut' 'äöü.txt');
   yourself.

  => http://myhost/path/with/unlaut/%C3%A4%C3%B6%C3%BC.txt

Class comments and unit tests should help.

There is also this draft:

   http://stfx.eu/EnterprisePharo/Zinc-Encoding-Meta/

HTH,

Sven

PS: Incidentally, this does work

   'http://myhost/path/with/umlaut/äöü.txt' asFileReference asUrl.

because #asFileReference works differently.


On 02 Dec 2014, at 23:32, Udo Schneider  wrote:

All,

What's the expected behavior with non-ASCII characters in URLs. Let's say I want to access a 
file named "äöü.txt" - My assumption was that Zinc takes care of the UTF-8 -> 7bit 
(ASCII) -> Escape encoding. But there is either something I don't understand or some manual 
steps I'm missing.

The "straightforward" way doesn't work:
'http://myhost/path/with/umlaut/äöü.txt' asUrl. "ZnCharacterEncodingError: ASCII 
character expected"

Although the actual encoding seems to be able to handle it (ignoring the 
escapes slashes for the moment:
'http://myhost/path/with/umlaut/äöü.txt' urlEncoded.
"'http%3A%2F%2Fmyhost%2Fpath%2Fwith%2Fumlaut%2F%C3%A4%C3%B6%C3%BC.txt'"

Creating a URL from already escaped characters works as well:
'http://myhost/path/with/umlaut/%C3%A4%C3%B6%C3%BC.txt' asUrl.
"http://myhost/path/with/umlaut/%C3%A4%C3%B6%C3%BC.txt";

As does the decoding of such an URL:
'http://myhost/path/with/umlaut/%C3%A4%C3%B6%C3%BC.txt' urlDecoded.
"'http://myhost/path/with/umlaut/äöü.txt'"

At them moment I'm manually encoding UTF-8 characters in paths segments before 
trying to build the URL. But is this the correct way?

Best Regards,

Udo