|
[HtmlUnit] Migration from java.net.URL to java.net.URI
Hi,
I've started working on the migration from URL to URI and I would be
interested in your opinion on the scope of the changes that we should do.
I think that internally we shouldn't use URL anymore and use URI instead
everywhere. Where I'm not sure is concerning what should be visible to
users. I believe for instance that WebClient.getPage(URL) should not be
deprecated as it the main entry point since a very long time for all
HtmlUnit users. On the other side, I think that URL related methods
could be deprecated on classes like WebRequestSettings without problem.
An other question concerns the naming. Should we use methods like
getUri() to return a java.net.URI or can we have a getUrl() to return
something else than a java.net.URL due to the common understanding of URL?
Thoughts?
Cheers,
Marc.
--
Web: http://www.efficient-webtesting.comBlog: http://mguillem.wordpress.com------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference_______________________________________________
HtmlUnit-develop mailing list
HtmlUnit-develop@...
https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
|
|
Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi Marc,
I am with having all 'non-internal' methods, to have only URL, and the name would be getUrl(). So, users do not face any 'URI'.
However, if it is a must to return a URI, then getUri() is useful. But again, we shouldn't return URI directly (there is java.net.Uri.toURL()).
Also, there might be cases where only 'path' or 'query' are needed to be returned.
Yours,
Ahmed ---- Blog: http://asashour.blogspot.com
From: Marc Guillemot <mguillemot@...>
To: htmlunit-develop@...
Sent: Mon, October 26, 2009 1:05:42 PM
Subject: [HtmlUnit] Migration from java.net.URL to java.net.URI
Hi, I've started working on the migration from URL to URI and I would be interested in your opinion on the scope of the changes that we should do. I think that internally we shouldn't use URL anymore and use URI instead everywhere. Where I'm not sure is concerning what should be visible to users. I believe for instance that WebClient.getPage(URL) should not be deprecated as it the main entry point since a very long time for all HtmlUnit users. On the other side, I think that URL related methods could be deprecated on
classes like WebRequestSettings without problem. An other question concerns the naming. Should we use methods like getUri() to return a java.net.URI or can we have a getUrl() to return something else than a java.net.URL due to the common understanding of URL? Thoughts? Cheers, Marc. -- Web: http://www.efficient-webtesting.com Blog: http://mguillem.wordpress.com ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ HtmlUnit-develop mailing list HtmlUnit-develop@...https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference_______________________________________________
HtmlUnit-develop mailing list
HtmlUnit-develop@...
https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
|
|
Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
I would be OK with removing all URLs except from WebClient.getPage(URL) (with appropriate deprecation periods). The only other place I can think of with URLs that we might need to keep are one or two of the WebRequestSettings constructors.
If something returns a URI, I think it should be called getUri() (not getUrl()). Take care, Daniel On Mon, Oct 26, 2009 at 6:05 AM, Marc Guillemot <mguillemot@...> wrote:
Hi,
I've started working on the migration from URL to URI and I would be
interested in your opinion on the scope of the changes that we should do.
I think that internally we shouldn't use URL anymore and use URI instead
everywhere. Where I'm not sure is concerning what should be visible to
users. I believe for instance that WebClient.getPage(URL) should not be
deprecated as it the main entry point since a very long time for all
HtmlUnit users. On the other side, I think that URL related methods
could be deprecated on classes like WebRequestSettings without problem.
An other question concerns the naming. Should we use methods like
getUri() to return a java.net.URI or can we have a getUrl() to return
something else than a java.net.URL due to the common understanding of URL?
Thoughts?
Cheers,
Marc.
--
Web: http://www.efficient-webtesting.com
Blog: http://mguillem.wordpress.com
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
HtmlUnit-develop mailing list
HtmlUnit-develop@...
https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
-- Daniel Gredler http://daniel.gredler.net/
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference_______________________________________________
HtmlUnit-develop mailing list
HtmlUnit-develop@...
https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
|
|
Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
Ahmed,
if we still return URLs, we still have to instantiate custom
URLStreamHandler for URLs like about:, javascript: or data: and don't
solve the problem faced on GoogleAppEngine.
Cheers,
Marc.
--
Web: http://www.efficient-webtesting.comBlog: http://mguillem.wordpress.comAhmed Ashour wrote:
> Hi Marc,
>
> I am with having all 'non-internal' methods, to have only URL, and the
> name would be getUrl(). So, users do not face any 'URI'.
>
> However, if it is a must to return a URI, then getUri() is useful. But
> again, we shouldn't return URI directly (there is java.net.Uri.toURL()).
>
> Also, there might be cases where only 'path' or 'query' are needed to be
> returned.
>
> Yours,
> Ahmed
> ----
> Blog: http://asashour.blogspot.com>
>
> ------------------------------------------------------------------------
> *From:* Marc Guillemot < mguillemot@...>
> *To:* htmlunit-develop@...
> *Sent:* Mon, October 26, 2009 1:05:42 PM
> *Subject:* [HtmlUnit] Migration from java.net.URL to java.net.URI
>
> Hi,
>
> I've started working on the migration from URL to URI and I would be
> interested in your opinion on the scope of the changes that we should do.
>
> I think that internally we shouldn't use URL anymore and use URI instead
> everywhere. Where I'm not sure is concerning what should be visible to
> users. I believe for instance that WebClient.getPage(URL) should not be
> deprecated as it the main entry point since a very long time for all
> HtmlUnit users. On the other side, I think that URL related methods
> could be deprecated on classes like WebRequestSettings without problem.
>
> An other question concerns the naming. Should we use methods like
> getUri() to return a java.net < http://java.net/>.URI or can we have a
> getUrl() to return
> something else than a java.net.URL due to the common understanding of URL?
>
> Thoughts?
>
> Cheers,
> Marc.
> --
> Web: http://www.efficient-webtesting.com> Blog: http://mguillem.wordpress.com>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference> _______________________________________________
> HtmlUnit-develop mailing list
> HtmlUnit-develop@...
> <mailto: HtmlUnit-develop@...>
> https://lists.sourceforge.net/lists/listinfo/htmlunit-develop>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> HtmlUnit-develop mailing list
> HtmlUnit-develop@...
> https://lists.sourceforge.net/lists/listinfo/htmlunit-develop------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference_______________________________________________
HtmlUnit-develop mailing list
HtmlUnit-develop@...
https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
|
|
Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi Marc,
Just a question: where would we have the 'non-standard' URLs?
In other words, I don't think WebResponse.getUrl(), WebRequestSettings.getUrl() will ever return "javascript:" or "data:".
From: Marc Guillemot <mguillemot@...>
To: htmlunit-develop@...
Sent: Mon, October 26, 2009 2:33:53 PM
Subject: Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
Ahmed, if we still return URLs, we still have to instantiate custom URLStreamHandler for URLs like about:, javascript: or data: and don't solve the problem faced on GoogleAppEngine. Cheers, Marc. -- Web: http://www.efficient-webtesting.com Blog: http://mguillem.wordpress.com Ahmed Ashour wrote: > Hi Marc, > > I am with having all 'non-internal' methods, to have only URL, and the > name would be getUrl(). So, users do not face any 'URI'. > > However, if it is a must
to return a URI, then getUri() is useful. But > again, we shouldn't return URI directly (there is java.net.Uri.toURL()). > > Also, there might be cases where only 'path' or 'query' are needed to be > returned. > > Yours, > Ahmed > ---- > Blog: http://asashour.blogspot.com > > > ------------------------------------------------------------------------ > *From:* Marc Guillemot < mguillemot@...> > *To:* htmlunit-develop@...> *Sent:* Mon, October 26, 2009 1:05:42 PM > *Subject:* [HtmlUnit] Migration from java.net.URL to
java.net.URI > > Hi, > > I've started working on the migration from URL to URI and I would be > interested in your opinion on the scope of the changes that we should do. > > I think that internally we shouldn't use URL anymore and use URI instead > everywhere. Where I'm not sure is concerning what should be visible to > users. I believe for instance that WebClient.getPage(URL) should not be > deprecated as it the main entry point since a very long time for all > HtmlUnit users. On the other side, I think that URL related methods > could be deprecated on classes like WebRequestSettings without problem. > > An other question concerns the naming. Should we use methods like > getUri() to return a java.net <http://java.net/>.URI or can we have a > getUrl() to return > something else than a java.net.URL due to the common understanding of
URL? > > Thoughts? > > Cheers, > Marc. > -- > Web: http://www.efficient-webtesting.com> Blog: http://mguillem.wordpress.com> > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > HtmlUnit-develop mailing list > HtmlUnit-develop@... > <mailto: HtmlUnit-develop@...> > https://lists.sourceforge.net/lists/listinfo/htmlunit-develop> > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference> > > ------------------------------------------------------------------------ > > _______________________________________________ > HtmlUnit-develop mailing list > HtmlUnit-develop@...> https://lists.sourceforge.net/lists/listinfo/htmlunit-develop------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us
from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference_______________________________________________ HtmlUnit-develop mailing list HtmlUnit-develop@...https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference_______________________________________________
HtmlUnit-develop mailing list
HtmlUnit-develop@...
https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
|
|
Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
Hi Ahmed,
data: is probably not that much used as IE doesn't support it, but for
javascript:, you can have it for instance has src of an iframe.
Cheers,
Marc.
--
Web: http://www.efficient-webtesting.comBlog: http://mguillem.wordpress.comAhmed Ashour wrote:
> Hi Marc,
>
> Just a question: where would we have the 'non-standard' URLs?
> In other words, I don't think WebResponse.getUrl(),
> WebRequestSettings.getUrl() will ever return "javascript:" or "data:".
>
> Yours,
> Ahmed
> ----
> Blog: http://asashour.blogspot.com> ------------------------------------------------------------------------
> *From:* Marc Guillemot < mguillemot@...>
> *To:* htmlunit-develop@...
> *Sent:* Mon, October 26, 2009 2:33:53 PM
> *Subject:* Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
>
> Ahmed,
>
> if we still return URLs, we still have to instantiate custom
> URLStreamHandler for URLs like about:, javascript: or data: and don't
> solve the problem faced on GoogleAppEngine.
>
> Cheers,
> Marc.
> --
> Web: http://www.efficient-webtesting.com> Blog: http://mguillem.wordpress.com>
> Ahmed Ashour wrote:
> > Hi Marc,
> >
> > I am with having all 'non-internal' methods, to have only URL, and the
> > name would be getUrl(). So, users do not face any 'URI'.
> >
> > However, if it is a must to return a URI, then getUri() is useful. But
> > again, we shouldn't return URI directly (there is java.net
> < http://java.net.uri.to/>.Uri.toURL()).
> >
> > Also, there might be cases where only 'path' or 'query' are needed to be
> > returned.
> >
> > Yours,
> > Ahmed
> > ----
> > Blog: http://asashour.blogspot.com> >
> >
> > ------------------------------------------------------------------------
> > *From:* Marc Guillemot < mguillemot@... <mailto: mguillemot@...>>
> > *To:* htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > *Sent:* Mon, October 26, 2009 1:05:42 PM
> > *Subject:* [HtmlUnit] Migration from java.net < http://java.net/>.URL
> to java.net.URI
> >
> > Hi,
> >
> > I've started working on the migration from URL to URI and I would be
> > interested in your opinion on the scope of the changes that we should do.
> >
> > I think that internally we shouldn't use URL anymore and use URI instead
> > everywhere. Where I'm not sure is concerning what should be visible to
> > users. I believe for instance that WebClient.getPage(URL) should not be
> > deprecated as it the main entry point since a very long time for all
> > HtmlUnit users. On the other side, I think that URL related methods
> > could be deprecated on classes like WebRequestSettings without problem.
> >
> > An other question concerns the naming. Should we use methods like
> > getUri() to return a java.net < http://java.net/>.URI or can we have a
> > getUrl() to return
> > something else than a java.net.URL due to the common understanding of
> URL?
> >
> > Thoughts?
> >
> > Cheers,
> > Marc.
> > --
> > Web: http://www.efficient-webtesting.com
> < http://www.efficient-webtesting.com/>
> > Blog: http://mguillem.wordpress.com < http://mguillem.wordpress.com/>
> >
> >
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference_______________________________________________
HtmlUnit-develop mailing list
HtmlUnit-develop@...
https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
|
|
Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
Don't forget about:blank, too... I believe that's the default URL for frames. On Mon, Oct 26, 2009 at 10:03 AM, Marc Guillemot <mguillemot@...> wrote:
Hi Ahmed,
data: is probably not that much used as IE doesn't support it, but for
javascript:, you can have it for instance has src of an iframe.
Cheers,
Marc.
--
Web: http://www.efficient-webtesting.com
Blog: http://mguillem.wordpress.com
Ahmed Ashour wrote:
> Hi Marc,
>
> Just a question: where would we have the 'non-standard' URLs?
> In other words, I don't think WebResponse.getUrl(),
> WebRequestSettings.getUrl() will ever return "javascript:" or "data:".
>
> Yours,
> Ahmed
> ----
> Blog: http://asashour.blogspot.com
> ------------------------------------------------------------------------
> *From:* Marc Guillemot < mguillemot@...>
> *To:* htmlunit-develop@...
> *Sent:* Mon, October 26, 2009 2:33:53 PM
> *Subject:* Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
>
> Ahmed,
>
> if we still return URLs, we still have to instantiate custom
> URLStreamHandler for URLs like about:, javascript: or data: and don't
> solve the problem faced on GoogleAppEngine.
>
> Cheers,
> Marc.
> --
> Web: http://www.efficient-webtesting.com
> Blog: http://mguillem.wordpress.com
>
> Ahmed Ashour wrote:
> > Hi Marc,
> >
> > I am with having all 'non-internal' methods, to have only URL, and the
> > name would be getUrl(). So, users do not face any 'URI'.
> >
> > However, if it is a must to return a URI, then getUri() is useful. But
> > again, we shouldn't return URI directly (there is java.net
> >
> > Also, there might be cases where only 'path' or 'query' are needed to be
> > returned.
> >
> > Yours,
> > Ahmed
> > ----
> > Blog: http://asashour.blogspot.com
> >
> >
> > ------------------------------------------------------------------------
> <mailto:htmlunit-develop@...>
> > *Sent:* Mon, October 26, 2009 1:05:42 PM
> > *Subject:* [HtmlUnit] Migration from java.net <http://java.net/>.URL
> to java.net.URI
> >
> > Hi,
> >
> > I've started working on the migration from URL to URI and I would be
> > interested in your opinion on the scope of the changes that we should do.
> >
> > I think that internally we shouldn't use URL anymore and use URI instead
> > everywhere. Where I'm not sure is concerning what should be visible to
> > users. I believe for instance that WebClient.getPage(URL) should not be
> > deprecated as it the main entry point since a very long time for all
> > HtmlUnit users. On the other side, I think that URL related methods
> > could be deprecated on classes like WebRequestSettings without problem.
> >
> > An other question concerns the naming. Should we use methods like
> > getUri() to return a java.net < http://java.net/>.URI or can we have a
> > getUrl() to return
> > something else than a java.net.URL due to the common understanding of
> URL?
> >
> > Thoughts?
> >
> > Cheers,
> > Marc.
> > --
> > Web: http://www.efficient-webtesting.com
> >
> >
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
HtmlUnit-develop mailing list
HtmlUnit-develop@...
-- Daniel Gredler http://daniel.gredler.net/
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference_______________________________________________
HtmlUnit-develop mailing list
HtmlUnit-develop@...
https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
|
|
Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi all,
I did a quick search for getUrl() and found it only in WebRequestSettings, and I still believe real-life cases (frames URL, iframe.src, etc) will never be in WebRequestSettings.getUrl().
I may be wrong, but I believe the non-standard URLs are 'hidden' in the HtmlUnit code base or during JavaScript execution, not directly related to an API for the users.
I am not against removing .getUrl(), but only when it is not really necessary.
Ahmed
----
Blog: http://asashour.blogspot.com
From: Daniel Gredler <djgredler@...>
To: htmlunit-develop@...
Sent: Mon, October 26, 2009 5:47:27 PM
Subject: Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
Don't forget about:blank, too... I believe that's the default URL for frames.
On Mon, Oct 26, 2009 at 10:03 AM, Marc Guillemot <mguillemot@...> wrote:
Hi Ahmed,
data: is probably not that much used as IE doesn't support it, but for
javascript:, you can have it for instance has src of an iframe.
Cheers, Marc. -- Web: http://www.efficient-webtesting.com Blog: http://mguillem.wordpress.com Ahmed Ashour wrote: > Hi Marc, > > Just a question: where would we have the 'non-standard' URLs? > In other words, I don't think WebResponse.getUrl(), > WebRequestSettings.getUrl() will ever return "javascript:" or "data:". > > Yours, > Ahmed > ---- > Blog: http://asashour.blogspot.com > ------------------------------------------------------------------------ > *From:* Marc Guillemot < mguillemot@...> > *To:* htmlunit-develop@...> *Sent:* Mon, October 26, 2009 2:33:53
PM > *Subject:* Re: [HtmlUnit] Migration from java.net.URL to java.net.URI > > Ahmed, > > if we still return URLs, we still have to instantiate custom > URLStreamHandler for URLs like about:, javascript: or data: and don't > solve the problem faced on GoogleAppEngine. > > Cheers, > Marc. > -- > Web: http://www.efficient-webtesting.com> Blog: http://mguillem.wordpress.com> > Ahmed Ashour wrote: > > Hi Marc, > > > > I am with having all 'non-internal' methods, to have only URL, and the > > name would be getUrl(). So, users do not face any 'URI'. > > > > However, if it is a must to
return a URI, then getUri() is useful. But > > again, we shouldn't return URI directly (there is java.net > <http://java.net.uri.to/>.Uri.toURL()).
> > > > Also, there might be cases where only 'path' or 'query' are needed to be > > returned. > > > > Yours, > > Ahmed > > ---- > > Blog: http://asashour.blogspot.com> > > > > > ------------------------------------------------------------------------
> <mailto:htmlunit-develop@...>
> > *Sent:* Mon, October 26, 2009 1:05:42 PM
> > *Subject:* [HtmlUnit] Migration from java.net <http://java.net/>.URL
> to java.net.URI > > > > Hi, > > > > I've started working on the migration from URL to URI and I would be > > interested in your opinion on the scope of the changes that we should do. > > > > I think that internally we shouldn't use URL anymore and use URI instead > > everywhere. Where I'm not sure is concerning what should be visible to > > users. I believe for instance that WebClient.getPage(URL) should not be > > deprecated as it the main entry point since a very long time for all > > HtmlUnit users. On the other side, I think that URL related methods > > could be deprecated on classes like WebRequestSettings without problem. > > > > An other question concerns the naming. Should we use methods like > > getUri()
to return a java.net < http://java.net/>.URI or can we have a > > getUrl() to return > > something else than a java.net.URL due to the common understanding of > URL? > > > > Thoughts? > > > > Cheers, > > Marc. > > -- > > Web: http://www.efficient-webtesting.com> <http://www.efficient-webtesting.com/>
> > Blog: http://mguillem.wordpress.com <http://mguillem.wordpress.com/>
> > > > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ HtmlUnit-develop mailing list HtmlUnit-develop@... -- Daniel Gredler http://daniel.gredler.net/ ------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference_______________________________________________
HtmlUnit-develop mailing list
HtmlUnit-develop@...
https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
|
|
Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
Ahmed,
my motivation to migrate from URL to URI was boost recently by being
blocked on GAE due to iframes. As Daniel mentioned, (i)frames' first
content is about:blank. Additionally having a frame with about:blank as
sandbox is used by some AJAX frameworks as far as I can remember.
What do you propose exactly? To have both getUrl() and getUri() on
WebRequestSettings?
Cheers,
Marc.
Ahmed Ashour wrote:
> Hi all,
>
> I did a quick search for getUrl() and found it only in
> WebRequestSettings, and I still believe real-life cases (frames URL,
> iframe.src, etc) will never be in WebRequestSettings.getUrl().
>
> I may be wrong, but I believe the non-standard URLs are 'hidden' in the
> HtmlUnit code base or during JavaScript execution, not directly related
> to an API for the users.
>
> I am not against removing .getUrl(), but only when it is not really
> necessary.
>
> Ahmed
> ----
> Blog: http://asashour.blogspot.com> ------------------------------------------------------------------------
> *From:* Daniel Gredler < djgredler@...>
> *To:* htmlunit-develop@...
> *Sent:* Mon, October 26, 2009 5:47:27 PM
> *Subject:* Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
>
> Don't forget about:blank, too... I believe that's the default URL for
> frames.
>
>
> On Mon, Oct 26, 2009 at 10:03 AM, Marc Guillemot < mguillemot@...
> <mailto: mguillemot@...>> wrote:
>
> Hi Ahmed,
>
> data: is probably not that much used as IE doesn't support it, but for
> javascript:, you can have it for instance has src of an iframe.
>
> Cheers,
> Marc.
> --
> Web: http://www.efficient-webtesting.com> Blog: http://mguillem.wordpress.com>
> Ahmed Ashour wrote:
> > Hi Marc,
> >
> > Just a question: where would we have the 'non-standard' URLs?
> > In other words, I don't think WebResponse.getUrl(),
> > WebRequestSettings.getUrl() will ever return "javascript:" or
> "data:".
> >
> > Yours,
> > Ahmed
> > ----
> > Blog: http://asashour.blogspot.com> >
> ------------------------------------------------------------------------
> > *From:* Marc Guillemot < mguillemot@...
> <mailto: mguillemot@...>>
> > *To:* htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > *Sent:* Mon, October 26, 2009 2:33:53 PM
> > *Subject:* Re: [HtmlUnit] Migration from java.net
> < http://java.net/>.URL to java.net.URI
> >
> > Ahmed,
> >
> > if we still return URLs, we still have to instantiate custom
> > URLStreamHandler for URLs like about:, javascript: or data: and don't
> > solve the problem faced on GoogleAppEngine.
> >
> > Cheers,
> > Marc.
> > --
> > Web: http://www.efficient-webtesting.com> < http://www.efficient-webtesting.com/>
> > Blog: http://mguillem.wordpress.com < http://mguillem.wordpress.com/>
> >
> > Ahmed Ashour wrote:
> > > Hi Marc,
> > >
> > > I am with having all 'non-internal' methods, to have only URL,
> and the
> > > name would be getUrl(). So, users do not face any 'URI'.
> > >
> > > However, if it is a must to return a URI, then getUri() is
> useful. But
> > > again, we shouldn't return URI directly (there is java.net
> < http://java.net/>
> > < http://java.net.uri.to/>.Uri.toURL()).
> > >
> > > Also, there might be cases where only 'path' or 'query' are
> needed to be
> > > returned.
> > >
> > > Yours,
> > > Ahmed
> > > ----
> > > Blog: http://asashour.blogspot.com < http://asashour.blogspot.com/>
> > >
> > >
> > >
> ------------------------------------------------------------------------
> > > *From:* Marc Guillemot < mguillemot@...
> <mailto: mguillemot@...> <mailto: mguillemot@...
> <mailto: mguillemot@...>>>
> > > *To:* htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>
> > > *Sent:* Mon, October 26, 2009 1:05:42 PM
> > > *Subject:* [HtmlUnit] Migration from java.net
> < http://java.net/> < http://java.net/>.URL
> > to java.net.URI
> > >
> > > Hi,
> > >
> > > I've started working on the migration from URL to URI and I
> would be
> > > interested in your opinion on the scope of the changes that we
> should do.
> > >
> > > I think that internally we shouldn't use URL anymore and use
> URI instead
> > > everywhere. Where I'm not sure is concerning what should be
> visible to
> > > users. I believe for instance that WebClient.getPage(URL)
> should not be
> > > deprecated as it the main entry point since a very long time
> for all
> > > HtmlUnit users. On the other side, I think that URL related
> methods
> > > could be deprecated on classes like WebRequestSettings without
> problem.
> > >
> > > An other question concerns the naming. Should we use methods like
> > > getUri() to return a java.net < http://java.net/>
> < http://java.net/>.URI or can we have a
> > > getUrl() to return
> > > something else than a java.net.URL due to the common
> understanding of
> > URL?
> > >
> > > Thoughts?
> > >
> > > Cheers,
> > > Marc.
> > > --
> > > Web: http://www.efficient-webtesting.com> < http://www.efficient-webtesting.com/>
> > < http://www.efficient-webtesting.com/>
> > > Blog: http://mguillem.wordpress.com> < http://mguillem.wordpress.com/> < http://mguillem.wordpress.com/>
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference_______________________________________________
HtmlUnit-develop mailing list
HtmlUnit-develop@...
https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
|
|
Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi Marc,
I can see now, there is a constructor of "new WebRequestSettings(WebClient.URL_ABOUT_BLANK)" in BaseFrame.
I thought WebRequestSettings is only constructed by end users with real URLs, not "about:blank", "javascript:", etc.
So in this case, no issues, let's deprecate .getUrl() and document the replacement is .getUri().toURL()
Ahmed ---- Blog: http://asashour.blogspot.com
From: Marc Guillemot <mguillemot@...>
To: htmlunit-develop@...
Sent: Mon, October 26, 2009 7:02:26 PM
Subject: Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
Ahmed, my motivation to migrate from URL to URI was boost recently by being blocked on GAE due to iframes. As Daniel mentioned, (i)frames' first content is about:blank. Additionally having a frame with about:blank as sandbox is used by some AJAX frameworks as far as I can remember. What do you propose exactly? To have both getUrl() and getUri() on WebRequestSettings? Cheers, Marc. Ahmed Ashour wrote: > Hi all, > > I did a quick search for getUrl() and found it only in >
WebRequestSettings, and I still believe real-life cases (frames URL, > iframe.src, etc) will never be in WebRequestSettings.getUrl(). > > I may be wrong, but I believe the non-standard URLs are 'hidden' in the > HtmlUnit code base or during JavaScript execution, not directly related > to an API for the users. > > I am not against removing .getUrl(), but only when it is not really > necessary. > > Ahmed > ---- > Blog: http://asashour.blogspot.com > ------------------------------------------------------------------------ > *From:* Daniel Gredler < djgredler@...> > *To:* htmlunit-develop@...> *Sent:* Mon, October 26,
2009 5:47:27 PM > *Subject:* Re: [HtmlUnit] Migration from java.net.URL to java.net.URI > > Don't forget about:blank, too... I believe that's the default URL for > frames. > > > On Mon, Oct 26, 2009 at 10:03 AM, Marc Guillemot < mguillemot@... > <mailto: mguillemot@...>> wrote: > > Hi Ahmed, > > data: is probably not that much used as IE doesn't support it, but for > javascript:, you can have it for instance has src of an iframe. > > Cheers, > Marc. > -- > Web: http://www.efficient-webtesting.com > Blog:
http://mguillem.wordpress.com > > Ahmed Ashour wrote: > > Hi Marc, > > > > Just a question: where would we have the 'non-standard' URLs? > > In other words, I don't think WebResponse.getUrl(), > > WebRequestSettings.getUrl() will ever return "javascript:" or > "data:". > > > > Yours, > > Ahmed > > ---- > > Blog: http://asashour.blogspot.com> > > ------------------------------------------------------------------------ > > *From:* Marc Guillemot < mguillemot@...> <mailto: mguillemot@...>> > > *To:* htmlunit-develop@...> <mailto: htmlunit-develop@...> > > *Sent:* Mon, October 26, 2009 2:33:53 PM > > *Subject:* Re: [HtmlUnit] Migration from java.net > <http://java.net/>.URL to java.net.URI > > > > Ahmed, > > > > if we still return
URLs, we still have to instantiate custom > > URLStreamHandler for URLs like about:, javascript: or data: and don't > > solve the problem faced on GoogleAppEngine. > > > > Cheers, > > Marc. > > -- > > Web: http://www.efficient-webtesting.com> <http://www.efficient-webtesting.com/> > > Blog: http://mguillem.wordpress.com <http://mguillem.wordpress.com/> > > > > Ahmed Ashour wrote: > > > Hi Marc, > > > > >
> I am with having all 'non-internal' methods, to have only URL, > and the > > > name would be getUrl(). So, users do not face any 'URI'. > > > > > > However, if it is a must to return a URI, then getUri() is > useful. But > > > again, we shouldn't return URI directly (there is java.net > < http://java.net/> > > <http://java.net.uri.to/>.Uri.toURL()). > > > > > > Also, there might be cases where only 'path' or 'query' are > needed to be > > > returned. > > > >
> > Yours, > > > Ahmed > > > ---- > > > Blog: http://asashour.blogspot.com <http://asashour.blogspot.com/> > > > > > > > > > > ------------------------------------------------------------------------ > > > *From:* Marc Guillemot < mguillemot@...> <mailto: mguillemot@...> <mailto: mguillemot@...>
<mailto: mguillemot@...>>> > > > *To:* htmlunit-develop@...> <mailto: htmlunit-develop@...> > > <mailto: htmlunit-develop@...> <mailto: htmlunit-develop@...>> > > > *Sent:* Mon,
October 26, 2009 1:05:42 PM > > > *Subject:* [HtmlUnit] Migration from java.net > < http://java.net/> < http://java.net/>.URL > > to java.net.URI > > > > > > Hi, > > > > > > I've started working on the migration from URL to URI and I > would be > > > interested in your opinion on the scope of the changes that we > should do. > > > > > > I think that internally we shouldn't use URL anymore and use > URI instead > > >
everywhere. Where I'm not sure is concerning what should be > visible to > > > users. I believe for instance that WebClient.getPage(URL) > should not be > > > deprecated as it the main entry point since a very long time > for all > > > HtmlUnit users. On the other side, I think that URL related > methods > > > could be deprecated on classes like WebRequestSettings without > problem. > > > > > > An other question concerns the naming. Should we use methods like > > > getUri() to return a java.net < http://java.net/> > < http://java.net/>.URI or can we have a > > > getUrl() to return > > > something else than a java.net.URL due to the common > understanding of > > URL? > > > > > > Thoughts? > > > > > > Cheers, > > > Marc. > > > -- > > > Web: http://www.efficient-webtesting.com> < http://www.efficient-webtesting.com/> > > < http://www.efficient-webtesting.com/> > > > Blog: http://mguillem.wordpress.com> < http://mguillem.wordpress.com/> < http://mguillem.wordpress.com/> ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ HtmlUnit-develop mailing
list HtmlUnit-develop@...https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________
HtmlUnit-develop mailing list
HtmlUnit-develop@...
https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
|
|
Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
Hi,
I'm nearly ready with the migration from java.net.URL to java.net.URI...
and I know believe that we shouldn't use java.net.URI!
Or at least we shouldn't make it visible.
java.net.URI is stricter than java.net.URL concerning the content of the
URI and things like "javascript:'<html><body>hello</body></html>'" or
"javascript:void(alert(1 + 2))" are illegal.
One solution could be to have a kind of special handling for stuff like
that but in fact I think that we should look at this problem from the
other direction: basically we don't want to use java.net.URL or
java.net.URI, these are just possible solutions to achieve our goal. I
think that our goal is to be able to represent what can be entered in
the address field of a browser or what can be correctly evaluated as
href of a link, src of an (i)frame or img, .... With this requirement,
we need a custom class that is able to handle the flexibility that we
need as well as to expose accessors to convert for instance to
java.net.URL (or URI).
What do you think?
Cheers,
Marc.
Ahmed Ashour a écrit :
> Hi Marc,
>
> I can see now, there is a constructor of "new
> WebRequestSettings(WebClient.URL_ABOUT_BLANK)" in BaseFrame.
>
> I thought WebRequestSettings is only constructed by end users with real
> URLs, not "about:blank", "javascript:", etc.
>
> So in this case, no issues, let's deprecate .getUrl() and document the
> replacement is .getUri().toURL()
> Ahmed
> ----
> Blog: http://asashour.blogspot.com>
>
> ------------------------------------------------------------------------
> *From:* Marc Guillemot < mguillemot@...>
> *To:* htmlunit-develop@...
> *Sent:* Mon, October 26, 2009 7:02:26 PM
> *Subject:* Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
>
> Ahmed,
>
> my motivation to migrate from URL to URI was boost recently by being
> blocked on GAE due to iframes. As Daniel mentioned, (i)frames' first
> content is about:blank. Additionally having a frame with about:blank as
> sandbox is used by some AJAX frameworks as far as I can remember.
>
> What do you propose exactly? To have both getUrl() and getUri() on
> WebRequestSettings?
>
> Cheers,
> Marc.
>
> Ahmed Ashour wrote:
> > Hi all,
> >
> > I did a quick search for getUrl() and found it only in
> > WebRequestSettings, and I still believe real-life cases (frames URL,
> > iframe.src, etc) will never be in WebRequestSettings.getUrl().
> >
> > I may be wrong, but I believe the non-standard URLs are 'hidden' in the
> > HtmlUnit code base or during JavaScript execution, not directly related
> > to an API for the users.
> >
> > I am not against removing .getUrl(), but only when it is not really
> > necessary.
> >
> > Ahmed
> > ----
> > Blog: http://asashour.blogspot.com> > ------------------------------------------------------------------------
> > *From:* Daniel Gredler < djgredler@... <mailto: djgredler@...>>
> > *To:* htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > *Sent:* Mon, October 26, 2009 5:47:27 PM
> > *Subject:* Re: [HtmlUnit] Migration from java.net
> < http://java.net/>.URL to java.net.URI
> >
> > Don't forget about:blank, too... I believe that's the default URL for
> > frames.
> >
> >
> > On Mon, Oct 26, 2009 at 10:03 AM, Marc Guillemot < mguillemot@...
> <mailto: mguillemot@...>
> > <mailto: mguillemot@... <mailto: mguillemot@...>>> wrote:
> >
> > Hi Ahmed,
> >
> > data: is probably not that much used as IE doesn't support it, but for
> > javascript:, you can have it for instance has src of an iframe.
> >
> > Cheers,
> > Marc.
> > --
> > Web: http://www.efficient-webtesting.com> > Blog: http://mguillem.wordpress.com> >
> > Ahmed Ashour wrote:
> > > Hi Marc,
> > >
> > > Just a question: where would we have the 'non-standard' URLs?
> > > In other words, I don't think WebResponse.getUrl(),
> > > WebRequestSettings.getUrl() will ever return "javascript:" or
> > "data:".
> > >
> > > Yours,
> > > Ahmed
> > > ----
> > > Blog: http://asashour.blogspot.com < http://asashour.blogspot.com/>
> > >
> >
> ------------------------------------------------------------------------
> > > *From:* Marc Guillemot < mguillemot@...
> <mailto: mguillemot@...>
> > <mailto: mguillemot@... <mailto: mguillemot@...>>>
> > > *To:* htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>
> > > *Sent:* Mon, October 26, 2009 2:33:53 PM
> > > *Subject:* Re: [HtmlUnit] Migration from java.net
> > < http://java.net/>.URL to java.net.URI
> > >
> > > Ahmed,
> > >
> > > if we still return URLs, we still have to instantiate custom
> > > URLStreamHandler for URLs like about:, javascript: or data:
> and don't
> > > solve the problem faced on GoogleAppEngine.
> > >
> > > Cheers,
> > > Marc.
> > > --
> > > Web: http://www.efficient-webtesting.com
> < http://www.efficient-webtesting.com/>
> > < http://www.efficient-webtesting.com/>
> > > Blog: http://mguillem.wordpress.com
> < http://mguillem.wordpress.com/> < http://mguillem.wordpress.com/>
> > >
> > > Ahmed Ashour wrote:
> > > > Hi Marc,
> > > >
> > > > I am with having all 'non-internal' methods, to have only URL,
> > and the
> > > > name would be getUrl(). So, users do not face any 'URI'.
> > > >
> > > > However, if it is a must to return a URI, then getUri() is
> > useful. But
> > > > again, we shouldn't return URI directly (there is java.net
> > < http://java.net/>
> > > < http://java.net.uri.to/>.Uri.toURL()).
> > > >
> > > > Also, there might be cases where only 'path' or 'query' are
> > needed to be
> > > > returned.
> > > >
> > > > Yours,
> > > > Ahmed
> > > > ----
> > > > Blog: http://asashour.blogspot.com
> < http://asashour.blogspot.com/> < http://asashour.blogspot.com/>
> > > >
> > > >
> > > >
> >
> ------------------------------------------------------------------------
> > > > *From:* Marc Guillemot < mguillemot@...
> <mailto: mguillemot@...>
> > <mailto: mguillemot@... <mailto: mguillemot@...>>
> <mailto: mguillemot@... <mailto: mguillemot@...>
> > <mailto: mguillemot@... <mailto: mguillemot@...>>>>
> > > > *To:* htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>
> > > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>>
> > > > *Sent:* Mon, October 26, 2009 1:05:42 PM
> > > > *Subject:* [HtmlUnit] Migration from java.net
> > < http://java.net/> < http://java.net/>.URL
> > > to java.net.URI
> > > >
> > > > Hi,
> > > >
> > > > I've started working on the migration from URL to URI and I
> > would be
> > > > interested in your opinion on the scope of the changes that we
> > should do.
> > > >
> > > > I think that internally we shouldn't use URL anymore and use
> > URI instead
> > > > everywhere. Where I'm not sure is concerning what should be
> > visible to
> > > > users. I believe for instance that WebClient.getPage(URL)
> > should not be
> > > > deprecated as it the main entry point since a very long time
> > for all
> > > > HtmlUnit users. On the other side, I think that URL related
> > methods
> > > > could be deprecated on classes like WebRequestSettings without
> > problem.
> > > >
> > > > An other question concerns the naming. Should we use
> methods like
> > > > getUri() to return a java.net < http://java.net/>
> > < http://java.net/>.URI or can we have a
> > > > getUrl() to return
> > > > something else than a java.net.URL due to the common
> > understanding of
> > > URL?
> > > >
> > > > Thoughts?
> > > >
> > > > Cheers,
> > > > Marc.
> > > > --
> > > > Web: http://www.efficient-webtesting.com
> < http://www.efficient-webtesting.com/>
> > < http://www.efficient-webtesting.com/>
> > > < http://www.efficient-webtesting.com/>
> > > > Blog: http://mguillem.wordpress.com
> < http://mguillem.wordpress.com/>
> > < http://mguillem.wordpress.com/> < http://mguillem.wordpress.com/>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference> _______________________________________________
> HtmlUnit-develop mailing list
> HtmlUnit-develop@...
> <mailto: HtmlUnit-develop@...>
> https://lists.sourceforge.net/lists/listinfo/htmlunit-develop>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> HtmlUnit-develop mailing list
> HtmlUnit-develop@...
> https://lists.sourceforge.net/lists/listinfo/htmlunit-develop------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________
HtmlUnit-develop mailing list
HtmlUnit-develop@...
https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
|
|
Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
This sounds like a sensible option; if you're sure that URI and URL both have too many issues, I don't have a problem with adopting a custom solution... but what do we call it? ;-)
On Mon, Nov 9, 2009 at 11:46 AM, Marc Guillemot <mguillemot@...> wrote:
Hi,
I'm nearly ready with the migration from java.net.URL to java.net.URI...
and I know believe that we shouldn't use java.net.URI!
Or at least we shouldn't make it visible.
java.net.URI is stricter than java.net.URL concerning the content of the
URI and things like "javascript:'<html><body>hello</body></html>'" or
"javascript:void(alert(1 + 2))" are illegal.
One solution could be to have a kind of special handling for stuff like
that but in fact I think that we should look at this problem from the
other direction: basically we don't want to use java.net.URL or
java.net.URI, these are just possible solutions to achieve our goal. I
think that our goal is to be able to represent what can be entered in
the address field of a browser or what can be correctly evaluated as
href of a link, src of an (i)frame or img, .... With this requirement,
we need a custom class that is able to handle the flexibility that we
need as well as to expose accessors to convert for instance to
java.net.URL (or URI).
What do you think?
Cheers,
Marc.
Ahmed Ashour a écrit :
> Hi Marc,
>
> I can see now, there is a constructor of "new
> WebRequestSettings(WebClient.URL_ABOUT_BLANK)" in BaseFrame.
>
> I thought WebRequestSettings is only constructed by end users with real
> URLs, not "about:blank", "javascript:", etc.
>
> So in this case, no issues, let's deprecate .getUrl() and document the
> replacement is .getUri().toURL()
> Ahmed
> ----
> Blog: http://asashour.blogspot.com
>
>
> ------------------------------------------------------------------------
> *From:* Marc Guillemot < mguillemot@...>
> *To:* htmlunit-develop@...
> *Sent:* Mon, October 26, 2009 7:02:26 PM
> *Subject:* Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
>
> Ahmed,
>
> my motivation to migrate from URL to URI was boost recently by being
> blocked on GAE due to iframes. As Daniel mentioned, (i)frames' first
> content is about:blank. Additionally having a frame with about:blank as
> sandbox is used by some AJAX frameworks as far as I can remember.
>
> What do you propose exactly? To have both getUrl() and getUri() on
> WebRequestSettings?
>
> Cheers,
> Marc.
>
> Ahmed Ashour wrote:
> > Hi all,
> >
> > I did a quick search for getUrl() and found it only in
> > WebRequestSettings, and I still believe real-life cases (frames URL,
> > iframe.src, etc) will never be in WebRequestSettings.getUrl().
> >
> > I may be wrong, but I believe the non-standard URLs are 'hidden' in the
> > HtmlUnit code base or during JavaScript execution, not directly related
> > to an API for the users.
> >
> > I am not against removing .getUrl(), but only when it is not really
> > necessary.
> >
> > Ahmed
> > ----
> > Blog: http://asashour.blogspot.com
> > ------------------------------------------------------------------------
> > *Sent:* Mon, October 26, 2009 5:47:27 PM
> > *Subject:* Re: [HtmlUnit] Migration from java.net
> > Don't forget about:blank, too... I believe that's the default URL for
> > frames.
> >
> >
> > On Mon, Oct 26, 2009 at 10:03 AM, Marc Guillemot < mguillemot@...
> <mailto: mguillemot@...>
> > <mailto: mguillemot@... <mailto: mguillemot@...>>> wrote:
> >
> > Hi Ahmed,
> >
> > data: is probably not that much used as IE doesn't support it, but for
> > javascript:, you can have it for instance has src of an iframe.
> >
> > Cheers,
> > Marc.
> > --
> > Web: http://www.efficient-webtesting.com
> > Blog: http://mguillem.wordpress.com
> >
> > Ahmed Ashour wrote:
> > > Hi Marc,
> > >
> > > Just a question: where would we have the 'non-standard' URLs?
> > > In other words, I don't think WebResponse.getUrl(),
> > > WebRequestSettings.getUrl() will ever return "javascript:" or
> > "data:".
> > >
> > > Yours,
> > > Ahmed
> > > ----
> > > *Sent:* Mon, October 26, 2009 2:33:53 PM
> > > *Subject:* Re: [HtmlUnit] Migration from java.net
> > < http://java.net/>.URL to java.net.URI
> > >
> > > Ahmed,
> > >
> > > if we still return URLs, we still have to instantiate custom
> > > URLStreamHandler for URLs like about:, javascript: or data:
> and don't
> > > solve the problem faced on GoogleAppEngine.
> > >
> > > Cheers,
> > > Marc.
> > > --
> > > Web: http://www.efficient-webtesting.com
> < http://www.efficient-webtesting.com/>
> > > Ahmed Ashour wrote:
> > > > Hi Marc,
> > > >
> > > > I am with having all 'non-internal' methods, to have only URL,
> > and the
> > > > name would be getUrl(). So, users do not face any 'URI'.
> > > >
> > > > However, if it is a must to return a URI, then getUri() is
> > useful. But
> > > > again, we shouldn't return URI directly (there is java.net
> > < http://java.net/>
> > > < http://java.net.uri.to/>.Uri.toURL()).
> > > >
> > > > Also, there might be cases where only 'path' or 'query' are
> > needed to be
> > > > returned.
> > > >
> > > > Yours,
> > > > Ahmed
> > > > ----
> > > > Blog: http://asashour.blogspot.com
> > <mailto:mguillemot@... <mailto:mguillemot@...>>>>
> <mailto:HtmlUnit-develop@...>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>
>
> ------------------------------------------------------------------------
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
-- Daniel Gredler http://daniel.gredler.net/
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________
HtmlUnit-develop mailing list
HtmlUnit-develop@...
https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
|
|
Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
Finding the right name is often the most difficult problem. What about
something like WebAddress? or Location?
Cheers,
Marc.
Daniel Gredler a écrit :
> This sounds like a sensible option; if you're sure that URI and URL both
> have too many issues, I don't have a problem with adopting a custom
> solution... but what do we call it? ;-)
>
>
> On Mon, Nov 9, 2009 at 11:46 AM, Marc Guillemot < mguillemot@...
> <mailto: mguillemot@...>> wrote:
>
> Hi,
>
> I'm nearly ready with the migration from java.net.URL to java.net.URI...
> and I know believe that we shouldn't use java.net.URI!
> Or at least we shouldn't make it visible.
>
> java.net.URI is stricter than java.net.URL concerning the content of the
> URI and things like "javascript:'<html><body>hello</body></html>'" or
> "javascript:void(alert(1 + 2))" are illegal.
>
> One solution could be to have a kind of special handling for stuff like
> that but in fact I think that we should look at this problem from the
> other direction: basically we don't want to use java.net.URL or
> java.net.URI, these are just possible solutions to achieve our goal. I
> think that our goal is to be able to represent what can be entered in
> the address field of a browser or what can be correctly evaluated as
> href of a link, src of an (i)frame or img, .... With this requirement,
> we need a custom class that is able to handle the flexibility that we
> need as well as to expose accessors to convert for instance to
> java.net.URL (or URI).
>
> What do you think?
>
> Cheers,
> Marc.
>
> Ahmed Ashour a écrit :
> > Hi Marc,
> >
> > I can see now, there is a constructor of "new
> > WebRequestSettings(WebClient.URL_ABOUT_BLANK)" in BaseFrame.
> >
> > I thought WebRequestSettings is only constructed by end users
> with real
> > URLs, not "about:blank", "javascript:", etc.
> >
> > So in this case, no issues, let's deprecate .getUrl() and
> document the
> > replacement is .getUri().toURL()
> > Ahmed
> > ----
> > Blog: http://asashour.blogspot.com> >
> >
> >
> ------------------------------------------------------------------------
> > *From:* Marc Guillemot < mguillemot@...
> <mailto: mguillemot@...>>
> > *To:* htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > *Sent:* Mon, October 26, 2009 7:02:26 PM
> > *Subject:* Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
> >
> > Ahmed,
> >
> > my motivation to migrate from URL to URI was boost recently by being
> > blocked on GAE due to iframes. As Daniel mentioned, (i)frames' first
> > content is about:blank. Additionally having a frame with
> about:blank as
> > sandbox is used by some AJAX frameworks as far as I can remember.
> >
> > What do you propose exactly? To have both getUrl() and getUri() on
> > WebRequestSettings?
> >
> > Cheers,
> > Marc.
> >
> > Ahmed Ashour wrote:
> > > Hi all,
> > >
> > > I did a quick search for getUrl() and found it only in
> > > WebRequestSettings, and I still believe real-life cases
> (frames URL,
> > > iframe.src, etc) will never be in WebRequestSettings.getUrl().
> > >
> > > I may be wrong, but I believe the non-standard URLs are
> 'hidden' in the
> > > HtmlUnit code base or during JavaScript execution, not
> directly related
> > > to an API for the users.
> > >
> > > I am not against removing .getUrl(), but only when it is not
> really
> > > necessary.
> > >
> > > Ahmed
> > > ----
> > > Blog: http://asashour.blogspot.com> > >
> ------------------------------------------------------------------------
> > > *From:* Daniel Gredler < djgredler@...
> <mailto: djgredler@...> <mailto: djgredler@...
> <mailto: djgredler@...>>>
> > > *To:* htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>
> > > *Sent:* Mon, October 26, 2009 5:47:27 PM
> > > *Subject:* Re: [HtmlUnit] Migration from java.net
> < http://java.net>
> > < http://java.net/>.URL to java.net.URI
> > >
> > > Don't forget about:blank, too... I believe that's the default
> URL for
> > > frames.
> > >
> > >
> > > On Mon, Oct 26, 2009 at 10:03 AM, Marc Guillemot
> < mguillemot@... <mailto: mguillemot@...>
> > <mailto: mguillemot@... <mailto: mguillemot@...>>
> > > <mailto: mguillemot@... <mailto: mguillemot@...>
> <mailto: mguillemot@... <mailto: mguillemot@...>>>> wrote:
> > >
> > > Hi Ahmed,
> > >
> > > data: is probably not that much used as IE doesn't support
> it, but for
> > > javascript:, you can have it for instance has src of an iframe.
> > >
> > > Cheers,
> > > Marc.
> > > --
> > > Web: http://www.efficient-webtesting.com> > > Blog: http://mguillem.wordpress.com> > >
> > > Ahmed Ashour wrote:
> > > > Hi Marc,
> > > >
> > > > Just a question: where would we have the 'non-standard'
> URLs?
> > > > In other words, I don't think WebResponse.getUrl(),
> > > > WebRequestSettings.getUrl() will ever return
> "javascript:" or
> > > "data:".
> > > >
> > > > Yours,
> > > > Ahmed
> > > > ----
> > > > Blog: http://asashour.blogspot.com> < http://asashour.blogspot.com/>
> > > >
> > >
> >
> ------------------------------------------------------------------------
> > > > *From:* Marc Guillemot < mguillemot@...
> <mailto: mguillemot@...>
> > <mailto: mguillemot@... <mailto: mguillemot@...>>
> > > <mailto: mguillemot@... <mailto: mguillemot@...>
> <mailto: mguillemot@... <mailto: mguillemot@...>>>>
> > > > *To:* htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>
> > > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>>
> > > > *Sent:* Mon, October 26, 2009 2:33:53 PM
> > > > *Subject:* Re: [HtmlUnit] Migration from java.net
> < http://java.net>
> > > < http://java.net/>.URL to java.net.URI
> > > >
> > > > Ahmed,
> > > >
> > > > if we still return URLs, we still have to instantiate
> custom
> > > > URLStreamHandler for URLs like about:, javascript: or data:
> > and don't
> > > > solve the problem faced on GoogleAppEngine.
> > > >
> > > > Cheers,
> > > > Marc.
> > > > --
> > > > Web: http://www.efficient-webtesting.com> > < http://www.efficient-webtesting.com/>
> > > < http://www.efficient-webtesting.com/>
> > > > Blog: http://mguillem.wordpress.com> > < http://mguillem.wordpress.com/> < http://mguillem.wordpress.com/>
> > > >
> > > > Ahmed Ashour wrote:
> > > > > Hi Marc,
> > > > >
> > > > > I am with having all 'non-internal' methods, to have
> only URL,
> > > and the
> > > > > name would be getUrl(). So, users do not face any 'URI'.
> > > > >
> > > > > However, if it is a must to return a URI, then
> getUri() is
> > > useful. But
> > > > > again, we shouldn't return URI directly (there is
> java.net < http://java.net>
> > > < http://java.net/>
> > > > < http://java.net.uri.to/>.Uri.toURL()).
> > > > >
> > > > > Also, there might be cases where only 'path' or
> 'query' are
> > > needed to be
> > > > > returned.
> > > > >
> > > > > Yours,
> > > > > Ahmed
> > > > > ----
> > > > > Blog: http://asashour.blogspot.com> > < http://asashour.blogspot.com/> < http://asashour.blogspot.com/>
> > > > >
> > > > >
> > > > >
> > >
> >
> ------------------------------------------------------------------------
> > > > > *From:* Marc Guillemot < mguillemot@...
> <mailto: mguillemot@...>
> > <mailto: mguillemot@... <mailto: mguillemot@...>>
> > > <mailto: mguillemot@... <mailto: mguillemot@...>
> <mailto: mguillemot@... <mailto: mguillemot@...>>>
> > <mailto: mguillemot@... <mailto: mguillemot@...>
> <mailto: mguillemot@... <mailto: mguillemot@...>>
> > > <mailto: mguillemot@... <mailto: mguillemot@...>
> <mailto: mguillemot@... <mailto: mguillemot@...>>>>>
> > > > > *To:* htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>
> > > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>>
> > > > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>
> > > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>>>
> > > > > *Sent:* Mon, October 26, 2009 1:05:42 PM
> > > > > *Subject:* [HtmlUnit] Migration from java.net
> < http://java.net>
> > > < http://java.net/> < http://java.net/>.URL
> > > > to java.net.URI
> > > > >
> > > > > Hi,
> > > > >
> > > > > I've started working on the migration from URL to
> URI and I
> > > would be
> > > > > interested in your opinion on the scope of the
> changes that we
> > > should do.
> > > > >
> > > > > I think that internally we shouldn't use URL anymore
> and use
> > > URI instead
> > > > > everywhere. Where I'm not sure is concerning what
> should be
> > > visible to
> > > > > users. I believe for instance that
> WebClient.getPage(URL)
> > > should not be
> > > > > deprecated as it the main entry point since a very
> long time
> > > for all
> > > > > HtmlUnit users. On the other side, I think that URL
> related
> > > methods
> > > > > could be deprecated on classes like
> WebRequestSettings without
> > > problem.
> > > > >
> > > > > An other question concerns the naming. Should we use
> > methods like
> > > > > getUri() to return a java.net < http://java.net>
> < http://java.net/>
> > > < http://java.net/>.URI or can we have a
> > > > > getUrl() to return
> > > > > something else than a java.net.URL due to the common
> > > understanding of
> > > > URL?
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Cheers,
> > > > > Marc.
> > > > > --
> > > > > Web: http://www.efficient-webtesting.com> > < http://www.efficient-webtesting.com/>
> > > < http://www.efficient-webtesting.com/>
> > > > < http://www.efficient-webtesting.com/>
> > > > > Blog: http://mguillem.wordpress.com> > < http://mguillem.wordpress.com/>
> > > < http://mguillem.wordpress.com/>
> < http://mguillem.wordpress.com/>
> >
> >
> >
> ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > is the only developer event you need to attend this year.
> Jumpstart your
> > developing skills, take BlackBerry mobile applications to market
> and stay
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference> > _______________________________________________
> > HtmlUnit-develop mailing list
> > HtmlUnit-develop@...
> <mailto: HtmlUnit-develop@...>
> > <mailto: HtmlUnit-develop@...
> <mailto: HtmlUnit-develop@...>>
> > https://lists.sourceforge.net/lists/listinfo/htmlunit-develop> >
> >
> >
> ------------------------------------------------------------------------
> >
> >
> ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports
> 2008 30-Day
> > trial. Simplify your report design, integration and deployment -
> and focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now. http://p.sf.net/sfu/bobj-july> >
> >
> >
> ------------------------------------------------------------------------
> >
> > _______________________________________________
> > HtmlUnit-develop mailing list
> > HtmlUnit-develop@...
> <mailto: HtmlUnit-develop@...>
> > https://lists.sourceforge.net/lists/listinfo/htmlunit-develop>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july> _______________________________________________
> HtmlUnit-develop mailing list
> HtmlUnit-develop@...
> <mailto: HtmlUnit-develop@...>
> https://lists.sourceforge.net/lists/listinfo/htmlunit-develop>
>
>
>
> --
> Daniel Gredler
> http://daniel.gredler.net/------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________
HtmlUnit-develop mailing list
HtmlUnit-develop@...
https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
|
|
Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi all,
As Daniel said, "if you're sure they both have many issues".
Location is confusing (and we already have JS object 'Location').
WebAddress seems to be a better option.
Ahmed
From: Marc Guillemot <mguillemot@...>
To: htmlunit-develop@...
Sent: Tue, November 10, 2009 9:36:59 AM
Subject: Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
Finding the right name is often the most difficult problem. What about something like WebAddress? or Location? Cheers, Marc. Daniel Gredler a écrit : > This sounds like a sensible option; if you're sure that URI and URL both > have too many issues, I don't have a problem with adopting a custom > solution... but what do we call it? ;-) > > > On Mon, Nov 9, 2009 at 11:46 AM, Marc Guillemot < mguillemot@...
> <mailto: mguillemot@...>> wrote: > > Hi, > > I'm nearly ready with the migration from java.net.URL to java.net.URI... > and I know believe that we shouldn't use java.net.URI! > Or at least we shouldn't make it visible. > > java.net.URI is stricter than java.net.URL concerning the content of the > URI and things like "javascript:'<html><body>hello</body></html>'" or > "javascript:void(alert(1 + 2))" are illegal. > > One solution could be to have a kind of special handling for stuff like > that but in fact I think that we should look at this problem from the > other
direction: basically we don't want to use java.net.URL or > java.net.URI, these are just possible solutions to achieve our goal. I > think that our goal is to be able to represent what can be entered in > the address field of a browser or what can be correctly evaluated as > href of a link, src of an (i)frame or img, .... With this requirement, > we need a custom class that is able to handle the flexibility that we > need as well as to expose accessors to convert for instance to > java.net.URL (or URI). > > What do you think? > > Cheers, > Marc. > > Ahmed Ashour a écrit : > > Hi Marc, > > > > I can see now, there is a constructor of
"new > > WebRequestSettings(WebClient.URL_ABOUT_BLANK)" in BaseFrame. > > > > I thought WebRequestSettings is only constructed by end users > with real > > URLs, not "about:blank", "javascript:", etc. > > > > So in this case, no issues, let's deprecate .getUrl() and > document the > > replacement is .getUri().toURL() > > Ahmed > > ---- > > Blog: http://asashour.blogspot.com > > > > > > > ------------------------------------------------------------------------ > > *From:* Marc Guillemot < mguillemot@...> <mailto: mguillemot@...>> > > *To:* htmlunit-develop@...> <mailto: htmlunit-develop@...> > > *Sent:* Mon, October 26, 2009 7:02:26 PM > > *Subject:* Re: [HtmlUnit] Migration from java.net.URL to java.net.URI > > > > Ahmed, > > > > my motivation to migrate from URL
to URI was boost recently by being > > blocked on GAE due to iframes. As Daniel mentioned, (i)frames' first > > content is about:blank. Additionally having a frame with > about:blank as > > sandbox is used by some AJAX frameworks as far as I can remember. > > > > What do you propose exactly? To have both getUrl() and getUri() on > > WebRequestSettings? > > > > Cheers, > > Marc. > > > > Ahmed Ashour wrote: > > > Hi all, > > > > > > I did a quick search for getUrl() and found it only in >
> > WebRequestSettings, and I still believe real-life cases > (frames URL, > > > iframe.src, etc) will never be in WebRequestSettings.getUrl(). > > > > > > I may be wrong, but I believe the non-standard URLs are > 'hidden' in the > > > HtmlUnit code base or during JavaScript execution, not > directly related > > > to an API for the users. > > > > > > I am not against removing .getUrl(), but only when it is not > really > > > necessary. > > > > > > Ahmed >
> > ---- > > > Blog: http://asashour.blogspot.com> > > > ------------------------------------------------------------------------ > > > *From:* Daniel Gredler < djgredler@...> <mailto: djgredler@...> <mailto: djgredler@...> <mailto: djgredler@...>>> > > > *To:* htmlunit-develop@...> <mailto: htmlunit-develop@...> > > <mailto: htmlunit-develop@...> <mailto: htmlunit-develop@...>> > > > *Sent:* Mon, October 26, 2009 5:47:27 PM > > > *Subject:* Re: [HtmlUnit] Migration from java.net > <http://java.net> > >
<http://java.net/>.URL to java.net.URI > > > > > > Don't forget about:blank, too... I believe that's the default > URL for > > > frames. > > > > > > > > > On Mon, Oct 26, 2009 at 10:03 AM, Marc Guillemot > < mguillemot@... <mailto: mguillemot@...> > > <mailto: mguillemot@... <mailto: mguillemot@...>> >
> > <mailto: mguillemot@... <mailto: mguillemot@...> > <mailto: mguillemot@... <mailto: mguillemot@...>>>> wrote: > > > > > > Hi Ahmed, > > > > > > data: is probably not that much used as IE doesn't support > it, but for > > > javascript:, you can have it for instance has src of an iframe. >
> > > > > Cheers, > > > Marc. > > > -- > > > Web: http://www.efficient-webtesting.com > > > Blog: http://mguillem.wordpress.com > > > > > > Ahmed Ashour wrote: > > > > Hi Marc, > > > > > > > > Just a question: where would we have the 'non-standard' > URLs? > > > > In other words, I don't think WebResponse.getUrl(), >
> > > WebRequestSettings.getUrl() will ever return > "javascript:" or > > > "data:". > > > > > > > > Yours, > > > > Ahmed > > > > ---- > > > > Blog: http://asashour.blogspot.com> <http://asashour.blogspot.com/> > > > > > > > > > > ------------------------------------------------------------------------ >
> > > *From:* Marc Guillemot < mguillemot@...> <mailto: mguillemot@...> > > <mailto: mguillemot@... <mailto: mguillemot@...>> > > > <mailto: mguillemot@... <mailto: mguillemot@...> > <mailto: mguillemot@... <mailto: mguillemot@...>>>> > > > > *To:* htmlunit-develop@...> <mailto: htmlunit-develop@...> > > <mailto: htmlunit-develop@...> <mailto: htmlunit-develop@...>> > > > <mailto: htmlunit-develop@...> <mailto: htmlunit-develop@...> > > <mailto: htmlunit-develop@...> <mailto: htmlunit-develop@...>>> > >
> > *Sent:* Mon, October 26, 2009 2:33:53 PM > > > > *Subject:* Re: [HtmlUnit] Migration from java.net > < http://java.net> > > > < http://java.net/>.URL to java.net.URI > > > > > > > > Ahmed, > > > > > > > > if we still return URLs, we still have to instantiate > custom > > > > URLStreamHandler for URLs like about:, javascript: or data: > > and
don't > > > > solve the problem faced on GoogleAppEngine. > > > > > > > > Cheers, > > > > Marc. > > > > -- > > > > Web: http://www.efficient-webtesting.com> > <http://www.efficient-webtesting.com/> > > > < http://www.efficient-webtesting.com/> > > > > Blog: http://mguillem.wordpress.com> > <http://mguillem.wordpress.com/> < http://mguillem.wordpress.com/> > > > > > > > > Ahmed Ashour wrote: > > > > > Hi Marc, > > > > > > > > > > I am with having all 'non-internal' methods, to have > only URL, > > > and the > > > > > name would be getUrl(). So, users do not face any 'URI'. > > >
> > > > > > > However, if it is a must to return a URI, then > getUri() is > > > useful. But > > > > > again, we shouldn't return URI directly (there is > java.net < http://java.net> > > > < http://java.net/> > > > > <http://java.net.uri.to/>.Uri.toURL()). > > > > > > > > > > Also, there might be cases where only 'path' or > 'query'
are > > > needed to be > > > > > returned. > > > > > > > > > > Yours, > > > > > Ahmed > > > > > ---- > > > > > Blog: http://asashour.blogspot.com> > < http://asashour.blogspot.com/> < http://asashour.blogspot.com/> > > >
> > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > *From:* Marc Guillemot < mguillemot@...> <mailto: mguillemot@...> > > <mailto: mguillemot@... <mailto: mguillemot@...>> >
> > <mailto: mguillemot@... <mailto: mguillemot@...> > <mailto: mguillemot@... <mailto: mguillemot@...>>> > > <mailto: mguillemot@... <mailto: mguillemot@...> > <mailto: mguillemot@... <mailto: mguillemot@...>> > > > <mailto: mguillemot@... <mailto: mguillemot@...> > <mailto: mguillemot@... <mailto: mguillemot@...>>>>> > > > > > *To:* htmlunit-develop@...> <mailto: htmlunit-develop@...> > > <mailto: htmlunit-develop@...> <mailto: htmlunit-develop@...>> > > > <mailto: htmlunit-develop@...> <mailto: htmlunit-develop@...> > > <mailto: htmlunit-develop@...> <mailto: htmlunit-develop@...>>> > > > > <mailto: htmlunit-develop@...> <mailto: htmlunit-develop@...> > > <mailto: htmlunit-develop@...> <mailto: htmlunit-develop@...>> > > > <mailto: htmlunit-develop@...> <mailto: htmlunit-develop@...> > > <mailto: htmlunit-develop@...> <mailto: htmlunit-develop@...>>>> > > > > > *Sent:* Mon, October 26, 2009 1:05:42 PM > > > > > *Subject:* [HtmlUnit] Migration from java.net > < http://java.net> > > > < http://java.net/> < http://java.net/>.URL > > > > to java.net.URI > > > > > > > > > >
Hi, > > > > > > > > > > I've started working on the migration from URL to > URI and I > > > would be > > > > > interested in your opinion on the scope of the > changes that we > > > should do. > > > > > > > > > > I think that internally we shouldn't use URL anymore > and use > > > URI instead > > > > > everywhere. Where I'm not sure is
concerning what > should be > > > visible to > > > > > users. I believe for instance that > WebClient.getPage(URL) > > > should not be > > > > > deprecated as it the main entry point since a very > long time > > > for all > > > > > HtmlUnit users. On the other side, I think that URL > related > > > methods > > > > > could be deprecated on classes like > WebRequestSettings
without > > > problem. > > > > > > > > > > An other question concerns the naming. Should we use > > methods like > > > > > getUri() to return a java.net < http://java.net> > < http://java.net/> > > > < http://java.net/>.URI or can we have a > > > > > getUrl() to return > > > > > something else than a java.net.URL
due to the common > > > understanding of > > > > URL? > > > > > > > > > > Thoughts? > > > > > > > > > > Cheers, > > > > > Marc. > > > > > -- > > > > > Web: http://www.efficient-webtesting.com> > < http://www.efficient-webtesting.com/> > > > < http://www.efficient-webtesting.com/> > > > > < http://www.efficient-webtesting.com/> > > > > > Blog: http://mguillem.wordpress.com> > < http://mguillem.wordpress.com/> > > > < http://mguillem.wordpress.com/> > < http://mguillem.wordpress.com/> > > > > > > > ------------------------------------------------------------------------------ > > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > > is the only developer event you need to attend this year. > Jumpstart your > > developing skills, take BlackBerry mobile applications to market > and stay > > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > > http://p.sf.net/sfu/devconference > > _______________________________________________ > > HtmlUnit-develop mailing list > > HtmlUnit-develop@...> <mailto: HtmlUnit-develop@...> > > <mailto: HtmlUnit-develop@...> <mailto: HtmlUnit-develop@...>> > > https://lists.sourceforge.net/lists/listinfo/htmlunit-develop>
> > > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------------ > > Let Crystal Reports handle the reporting - Free Crystal Reports > 2008 30-Day > > trial. Simplify your report design, integration and deployment - > and focus on > > what you do best, core application coding. Discover what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > > > > > >
------------------------------------------------------------------------ > > > > _______________________________________________ > > HtmlUnit-develop mailing list > > HtmlUnit-develop@...> <mailto: HtmlUnit-develop@...> > > https://lists.sourceforge.net/lists/listinfo/htmlunit-develop> > > ------------------------------------------------------------------------------ > Let Crystal
Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july> _______________________________________________ > HtmlUnit-develop mailing list > HtmlUnit-develop@...> <mailto: HtmlUnit-develop@...> > https://lists.sourceforge.net/lists/listinfo/htmlunit-develop> > > > > -- > Daniel Gredler > http://daniel.gredler.net/ ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________ HtmlUnit-develop mailing list HtmlUnit-develop@...https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________
HtmlUnit-develop mailing list
HtmlUnit-develop@...
https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
|
|
Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
in fact perhaps should we just handle it with... a String.
We would just perform cleanup, normalization, ... as we do today but
then set the "clean" value back to a String.
What do you think of this option?
Cheers,
Marc.
Ahmed Ashour a écrit :
> Hi all,
>
> As Daniel said, "if you're sure they both have many issues".
>
> Location is confusing (and we already have JS object 'Location').
>
> WebAddress seems to be a better option.
>
> Ahmed
>
> ------------------------------------------------------------------------
> *From:* Marc Guillemot < mguillemot@...>
> *To:* htmlunit-develop@...
> *Sent:* Tue, November 10, 2009 9:36:59 AM
> *Subject:* Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
>
> Finding the right name is often the most difficult problem. What about
> something like WebAddress? or Location?
>
> Cheers,
> Marc.
>
> Daniel Gredler a écrit :
> > This sounds like a sensible option; if you're sure that URI and URL both
> > have too many issues, I don't have a problem with adopting a custom
> > solution... but what do we call it? ;-)
> >
> >
> > On Mon, Nov 9, 2009 at 11:46 AM, Marc Guillemot < mguillemot@...
> <mailto: mguillemot@...>
> > <mailto: mguillemot@... <mailto: mguillemot@...>>> wrote:
> >
> > Hi,
> >
> > I'm nearly ready with the migration from java.net
> < http://java.net/>.URL to java.net.URI...
> > and I know believe that we shouldn't use java.net.URI!
> > Or at least we shouldn't make it visible.
> >
> > java.net.URI is stricter than java.net.URL concerning the content
> of the
> > URI and things like "javascript:'<html><body>hello</body></html>'" or
> > "javascript:void(alert(1 + 2))" are illegal.
> >
> > One solution could be to have a kind of special handling for stuff
> like
> > that but in fact I think that we should look at this problem from the
> > other direction: basically we don't want to use java.net.URL or
> > java.net.URI, these are just possible solutions to achieve our goal. I
> > think that our goal is to be able to represent what can be entered in
> > the address field of a browser or what can be correctly evaluated as
> > href of a link, src of an (i)frame or img, .... With this requirement,
> > we need a custom class that is able to handle the flexibility that we
> > need as well as to expose accessors to convert for instance to
> > java.net.URL (or URI).
> >
> > What do you think?
> >
> > Cheers,
> > Marc.
> >
> > Ahmed Ashour a écrit :
> > > Hi Marc,
> > >
> > > I can see now, there is a constructor of "new
> > > WebRequestSettings(WebClient.URL_ABOUT_BLANK)" in BaseFrame.
> > >
> > > I thought WebRequestSettings is only constructed by end users
> > with real
> > > URLs, not "about:blank", "javascript:", etc.
> > >
> > > So in this case, no issues, let's deprecate .getUrl() and
> > document the
> > > replacement is .getUri().toURL()
> > > Ahmed
> > > ----
> > > Blog: http://asashour.blogspot.com> > >
> > >
> > >
> >
> ------------------------------------------------------------------------
> > > *From:* Marc Guillemot < mguillemot@...
> <mailto: mguillemot@...>
> > <mailto: mguillemot@... <mailto: mguillemot@...>>>
> > > *To:* htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>
> > > *Sent:* Mon, October 26, 2009 7:02:26 PM
> > > *Subject:* Re: [HtmlUnit] Migration from java.net.URL to
> java.net.URI
> > >
> > > Ahmed,
> > >
> > > my motivation to migrate from URL to URI was boost recently by
> being
> > > blocked on GAE due to iframes. As Daniel mentioned, (i)frames'
> first
> > > content is about:blank. Additionally having a frame with
> > about:blank as
> > > sandbox is used by some AJAX frameworks as far as I can remember.
> > >
> > > What do you propose exactly? To have both getUrl() and getUri() on
> > > WebRequestSettings?
> > >
> > > Cheers,
> > > Marc.
> > >
> > > Ahmed Ashour wrote:
> > > > Hi all,
> > > >
> > > > I did a quick search for getUrl() and found it only in
> > > > WebRequestSettings, and I still believe real-life cases
> > (frames URL,
> > > > iframe.src, etc) will never be in WebRequestSettings.getUrl().
> > > >
> > > > I may be wrong, but I believe the non-standard URLs are
> > 'hidden' in the
> > > > HtmlUnit code base or during JavaScript execution, not
> > directly related
> > > > to an API for the users.
> > > >
> > > > I am not against removing .getUrl(), but only when it is not
> > really
> > > > necessary.
> > > >
> > > > Ahmed
> > > > ----
> > > > Blog: http://asashour.blogspot.com
> < http://asashour.blogspot.com/>
> > > >
> >
> ------------------------------------------------------------------------
> > > > *From:* Daniel Gredler < djgredler@...
> <mailto: djgredler@...>
> > <mailto: djgredler@... <mailto: djgredler@...>>
> <mailto: djgredler@... <mailto: djgredler@...>
> > <mailto: djgredler@... <mailto: djgredler@...>>>>
> > > > *To:* htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>
> > > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>>
> > > > *Sent:* Mon, October 26, 2009 5:47:27 PM
> > > > *Subject:* Re: [HtmlUnit] Migration from java.net
> > < http://java.net>
> > > < http://java.net/>.URL to java.net.URI
> > > >
> > > > Don't forget about:blank, too... I believe that's the default
> > URL for
> > > > frames.
> > > >
> > > >
> > > > On Mon, Oct 26, 2009 at 10:03 AM, Marc Guillemot
> > < mguillemot@... <mailto: mguillemot@...>
> <mailto: mguillemot@... <mailto: mguillemot@...>>
> > > <mailto: mguillemot@... <mailto: mguillemot@...>
> <mailto: mguillemot@... <mailto: mguillemot@...>>>
> > > > <mailto: mguillemot@... <mailto: mguillemot@...>
> <mailto: mguillemot@... <mailto: mguillemot@...>>
> > <mailto: mguillemot@... <mailto: mguillemot@...>
> <mailto: mguillemot@... <mailto: mguillemot@...>>>>> wrote:
> > > >
> > > > Hi Ahmed,
> > > >
> > > > data: is probably not that much used as IE doesn't support
> > it, but for
> > > > javascript:, you can have it for instance has src of an
> iframe.
> > > >
> > > > Cheers,
> > > > Marc.
> > > > --
> > > > Web: http://www.efficient-webtesting.com> > > > Blog: http://mguillem.wordpress.com> > > >
> > > > Ahmed Ashour wrote:
> > > > > Hi Marc,
> > > > >
> > > > > Just a question: where would we have the 'non-standard'
> > URLs?
> > > > > In other words, I don't think WebResponse.getUrl(),
> > > > > WebRequestSettings.getUrl() will ever return
> > "javascript:" or
> > > > "data:".
> > > > >
> > > > > Yours,
> > > > > Ahmed
> > > > > ----
> > > > > Blog: http://asashour.blogspot.com
> < http://asashour.blogspot.com/>
> > < http://asashour.blogspot.com/>
> > > > >
> > > >
> > >
> >
> ------------------------------------------------------------------------
> > > > > *From:* Marc Guillemot < mguillemot@...
> <mailto: mguillemot@...>
> > <mailto: mguillemot@... <mailto: mguillemot@...>>
> > > <mailto: mguillemot@... <mailto: mguillemot@...>
> <mailto: mguillemot@... <mailto: mguillemot@...>>>
> > > > <mailto: mguillemot@... <mailto: mguillemot@...>
> <mailto: mguillemot@... <mailto: mguillemot@...>>
> > <mailto: mguillemot@... <mailto: mguillemot@...>
> <mailto: mguillemot@... <mailto: mguillemot@...>>>>>
> > > > > *To:* htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>
> > > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>>
> > > > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>
> > > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>>>
> > > > > *Sent:* Mon, October 26, 2009 2:33:53 PM
> > > > > *Subject:* Re: [HtmlUnit] Migration from java.net
> > < http://java.net < http://java.net/>>
> > > > < http://java.net/>.URL to java.net.URI
> > > > >
> > > > > Ahmed,
> > > > >
> > > > > if we still return URLs, we still have to instantiate
> > custom
> > > > > URLStreamHandler for URLs like about:, javascript:
> or data:
> > > and don't
> > > > > solve the problem faced on GoogleAppEngine.
> > > > >
> > > > > Cheers,
> > > > > Marc.
> > > > > --
> > > > > Web: http://www.efficient-webtesting.com
> < http://www.efficient-webtesting.com/>
> > > < http://www.efficient-webtesting.com/>
> > > > < http://www.efficient-webtesting.com/>
> > > > > Blog: http://mguillem.wordpress.com
> < http://mguillem.wordpress.com/>
> > > < http://mguillem.wordpress.com/> < http://mguillem.wordpress.com/>
> > > > >
> > > > > Ahmed Ashour wrote:
> > > > > > Hi Marc,
> > > > > >
> > > > > > I am with having all 'non-internal' methods, to have
> > only URL,
> > > > and the
> > > > > > name would be getUrl(). So, users do not face any
> 'URI'.
> > > > > >
> > > > > > However, if it is a must to return a URI, then
> > getUri() is
> > > > useful. But
> > > > > > again, we shouldn't return URI directly (there is
> > java.net < http://java.net < http://java.net/>>
> > > > < http://java.net/>
> > > > > < http://java.net.uri.to/>.Uri.toURL()).
> > > > > >
> > > > > > Also, there might be cases where only 'path' or
> > 'query' are
> > > > needed to be
> > > > > > returned.
> > > > > >
> > > > > > Yours,
> > > > > > Ahmed
> > > > > > ----
> > > > > > Blog: http://asashour.blogspot.com
> < http://asashour.blogspot.com/>
> > > < http://asashour.blogspot.com/> < http://asashour.blogspot.com/>
> > > > > >
> > > > > >
> > > > > >
> > > >
> > >
> >
> ------------------------------------------------------------------------
> > > > > > *From:* Marc Guillemot < mguillemot@...
> <mailto: mguillemot@...>
> > <mailto: mguillemot@... <mailto: mguillemot@...>>
> > > <mailto: mguillemot@... <mailto: mguillemot@...>
> <mailto: mguillemot@... <mailto: mguillemot@...>>>
> > > > <mailto: mguillemot@... <mailto: mguillemot@...>
> <mailto: mguillemot@... <mailto: mguillemot@...>>
> > <mailto: mguillemot@... <mailto: mguillemot@...>
> <mailto: mguillemot@... <mailto: mguillemot@...>>>>
> > > <mailto: mguillemot@... <mailto: mguillemot@...>
> <mailto: mguillemot@... <mailto: mguillemot@...>>
> > <mailto: mguillemot@... <mailto: mguillemot@...>
> <mailto: mguillemot@... <mailto: mguillemot@...>>>
> > > > <mailto: mguillemot@... <mailto: mguillemot@...>
> <mailto: mguillemot@... <mailto: mguillemot@...>>
> > <mailto: mguillemot@... <mailto: mguillemot@...>
> <mailto: mguillemot@... <mailto: mguillemot@...>>>>>>
> > > > > > *To:* htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>
> > > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>>
> > > > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>
> > > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>>>
> > > > > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>
> > > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>>
> > > > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>
> > > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>
> > <mailto: htmlunit-develop@...
> <mailto: htmlunit-develop@...>>>>>
> > > > > > *Sent:* Mon, October 26, 2009 1:05:42 PM
> > > > > > *Subject:* [HtmlUnit] Migration from java.net
> > < http://java.net < http://java.net/>>
> > > > < http://java.net/> < http://java.net/>.URL
> > > > > to java.net.URI
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I've started working on the migration from URL to
> > URI and I
> > > > would be
> > > > > > interested in your opinion on the scope of the
> > changes that we
> > > > should do.
> > > > > >
> > > > > > I think that internally we shouldn't use URL anymore
> > and use
> > > > URI instead
> > > > > > everywhere. Where I'm not sure is concerning what
> > should be
> > > > visible to
> > > > > > users. I believe for instance that
> > WebClient.getPage(URL)
> > > > should not be
> > > > > > deprecated as it the main entry point since a very
> > long time
> > > > for all
> > > > > > HtmlUnit users. On the other side, I think that URL
> > related
> > > > methods
> > > > > > could be deprecated on classes like
> > WebRequestSettings without
> > > > problem.
> > > > > >
> > > > > > An other question concerns the naming. Should we use
> > > methods like
> > > > > > getUri() to return a java.net < http://java.net
> < http://java.net/>>
> > < http://java.net/>
> > > > < http://java.net/>.URI or can we have a
> > > > > > getUrl() to return
> > > > > > something else than a java.net.URL due to the common
> > > > understanding of
> > > > > URL?
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > Cheers,
> > > > > > Marc.
> > > > > > --
> > > > > > Web: http://www.efficient-webtesting.com
> < http://www.efficient-webtesting.com/>
> > > < http://www.efficient-webtesting.com/>
> > > > < http://www.efficient-webtesting.com/>
> > > > > < http://www.efficient-webtesting.com/>
> > > > > > Blog: http://mguillem.wordpress.com
> < http://mguillem.wordpress.com/>
> > > < http://mguillem.wordpress.com/>
> > > > < http://mguillem.wordpress.com/>
> > < http://mguillem.wordpress.com/>
> > >
> > >
> > >
> >
> ------------------------------------------------------------------------------
> > > Come build with us! The BlackBerry(R) Developer Conference in
> SF, CA
> > > is the only developer event you need to attend this year.
> > Jumpstart your
> > > developing skills, take BlackBerry mobile applications to market
> > and stay
> > > ahead of the curve. Join us from November 9 - 12, 2009.
> Register now!
> > > http://p.sf.net/sfu/devconference> > > _______________________________________________
> > > HtmlUnit-develop mailing list
> > > HtmlUnit-develop@...
> <mailto: HtmlUnit-develop@...>
> > <mailto: HtmlUnit-develop@...
> <mailto: HtmlUnit-develop@...>>
> > > <mailto: HtmlUnit-develop@...
> <mailto: HtmlUnit-develop@...>
> > <mailto: HtmlUnit-develop@...
> <mailto: HtmlUnit-develop@...>>>
> > > https://lists.sourceforge.net/lists/listinfo/htmlunit-develop> > >
> > >
> > >
> >
> ------------------------------------------------------------------------
> > >
> > >
> >
> ------------------------------------------------------------------------------
> > > Let Crystal Reports handle the reporting - Free Crystal Reports
> > 2008 30-Day
> > > trial. Simplify your report design, integration and deployment -
> > and focus on
> > > what you do best, core application coding. Discover what's new
> with
> > > Crystal Reports now. http://p.sf.net/sfu/bobj-july> > >
> > >
> > >
> >
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > HtmlUnit-develop mailing list
> > > HtmlUnit-develop@...
> <mailto: HtmlUnit-develop@...>
> > <mailto: HtmlUnit-develop@...
> <mailto: HtmlUnit-develop@...>>
> > > https://lists.sourceforge.net/lists/listinfo/htmlunit-develop> >
> >
> >
> ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> > 30-Day
> > trial. Simplify your report design, integration and deployment - and
> > focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now. http://p.sf.net/sfu/bobj-july> > _______________________________________________
> > HtmlUnit-develop mailing list
> > HtmlUnit-develop@...
> <mailto: HtmlUnit-develop@...>
> > <mailto: HtmlUnit-develop@...
> <mailto: HtmlUnit-develop@...>>
> > https://lists.sourceforge.net/lists/listinfo/htmlunit-develop> >
> >
> >
> >
> > --
> > Daniel Gredler
> > http://daniel.gredler.net/------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________
HtmlUnit-develop mailing list
HtmlUnit-develop@...
https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
|
|
Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
Some parts of this message have been removed.
Learn more about Nabble's security policy.
:)
As you know, with String, we won't have any support methods (getHost, setPort, getPrefix (e.g. "javascript:), getPath, etc etc etc).
I am sure the final decision will reach maturity over time, so let's start with the easiest step possible.
Ahmed
From: Marc Guillemot <mguillemot@...>
To: htmlunit-develop@...
Sent: Tue, November 10, 2009 10:13:06 AM
Subject: Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
in fact perhaps should we just handle it with... a String. We would just perform cleanup, normalization, ... as we do today but then set the "clean" value back to a String. What do you think of this option? Cheers, Marc.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________
HtmlUnit-develop mailing list
HtmlUnit-develop@...
https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
|
|
Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
Ahmed Ashour a écrit :
> :)
>
> As you know, with String, we won't have any support methods (getHost,
> setPort, getPrefix (e.g. "javascript:), getPath, etc etc etc).
that's sure, but where do we really need it? I think that this is only
at a few places and that having SomeUtil.getPath(myStringUrl) wouldn't
be an issue. Thoughts?
Cheers,
Marc.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________
HtmlUnit-develop mailing list
HtmlUnit-develop@...
https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
|
|
Re: [HtmlUnit] Migration from java.net.URL to java.net.URI
I would actually prefer a WebAddress (or Address?) class, even if the only instance var inside of it is a String... it just feels cleaner to have the "util" methods on the instances. But that's just a vague feeling :-)
Take care, Daniel On Tue, Nov 10, 2009 at 2:29 AM, Marc Guillemot <mguillemot@...> wrote:
Ahmed Ashour a écrit :
> :)
>
> As you know, with String, we won't have any support methods (getHost,
> setPort, getPrefix (e.g. "javascript:), getPath, etc etc etc).
that's sure, but where do we really need it? I think that this is only
at a few places and that having SomeUtil.getPath(myStringUrl) wouldn't
be an issue. Thoughts?
Cheers,
Marc.
-- Daniel Gredler http://daniel.gredler.net/
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________
HtmlUnit-develop mailing list
HtmlUnit-develop@...
https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
|
