Title: Message
Gino,
I would like to second Rich's point regarding passing enough information
to the portlet so that URLs can be written correctly in the first place if
needed.
An example I incidentally sent a couple of minutes ago to the WSIA group
(under a separate discussion) was a JavaScript example such as the
one below (which isn't necessarily a real one):
<script>
var target = "http://" + gMyDomain +
"/mypage.rgb?page="
+ document.form[1].pageNumber.value;
document.location = targert;
</script>
If such a script appears in a portlet, the
Portal has no way to route the action correctly, so if the Portlet won't change
the code, action routing won't work. So, I believe we need to let the Portlet
receive - as part of the protocol - the relevant Portal's URL to allow it to
generate the JavaScript correctly. This also means that if the Portlet is
sophisticated enough, it would also be able to write the rest of the URLs
correctly and save CPU time on the Portal end. And, this will also allow action
routing from Flash files, etc.
Please note that the same scenario is also
applicable to image routing, where in the common example of roll-over images,
the roll-over images are typically loaded using JavaScript
code.
My two cents,
Eilon
-----Original Message-----
From: Gino Filicetti
[mailto:]
Sent: Wednesday, May 08, 2002
5:05 PM
To: WSRP Mailing List (E-mail)
Subject:
[wsrp][markup] UPDATE: Minutes for 5/8/02 conference call
I've just included one of the URL demarcation proposals that
Rich recently
wrote up to the minutes in the URL
Rewriting section....
Please find the update minutes attached.
G
> -----Original Message-----
>
From: Gino Filicetti [mailto:]
> Sent: Wednesday, May 08, 2002 4:42 PM
> To: WSRP Mailing List (E-mail)
>
Subject: [wsrp][markup] Minutes for 5/8/02 conference call
>
>
>
Folks,
>
> Please find
attached the minutes for the latest conference call of the
> Markup subcommittee. The agenda we followed appears below.
>
> David Taieb will be
updating our master document to capture
> the
progress
> that was made in today's call and will
be sending that out
> for review in the
> next few days.
>
> Gino
>
>
> > PROPOSED AGENDA
> >
~~~~~~~~~~~~~~~
> >
>
> Markup Tags
> > ~~~~~~~~~~~
> > - The list of DISALLOWED and DISCOURAGED tags for
HTML and
> > XHTML Basic are
> > as follows:
> > HTML:
> > Disallowed: base, body, frame,
frameset, head, html, title
>
> Discouraged: link, meta, style
>
>
> > XHTML Basic:
> > Disallowed: base, body, head, html,
title
> >
Discouraged: link, meta
> >
> > - Question: What does it mean for a tag to be DISALLOWED?
> > Does the inclusion
> > of a disallowed tag invalidate the whole markup
fragment?
> >
> >
> > Style sheets
>
> ~~~~~~~~~~~~
> > - This is the full list of
styles submitted by Alan Kropp
> > (WSUI) and
Thomas
> > Schaeck
>
> (WSP) organized into groupings:
> >
> > Fonts:
> >
wsui-font
> > wsui-font-small
> > wsui-font-large
> >
wsui-dim
> > wsui-dim-small
> > wsui-error
> >
wsui-error-small
> > wsui-ok
> > wsui-ok-small
> >
wsui-form-label
> > portletText
> > portletSmText
> >
portletTinyText
> > buttonText
> > fieldErrorText
> >
> > Tables:
> > wsui-table
> >
wsui-table-row-header
> >
wsui-table-row-sectionheader
> >
wsui-table-row-odd
> >
wsui-table-row-even
> > tableHead
> > tableText
> >
tableShdRow
> >
>
> Sections:
> > wsui-section-title
> > wsui-trail
> >
wsui-trail-current
> > portletTitle
> > portletTitleCust
> >
portletHead
> > portletBody
> > portletBack
> >
> > General:
> >
wsui-page-title
> > wsui-block-bgcolor
> > portletColorBack
> >
> > Menus:
> >
wsui-menu
> > wsui-menu-current
> >
> > - we need to come up with a
naming convention, and rename all styles
> > -
we need to trim the list and delete duplicates
>
> - Question: Should the spec provide a default set of values
> > for the styles,
>
> or just
> > the names and a description of
the styles themselves?
> >
> >
> > Secure Resources
> > ~~~~~~~~~~~~~~~~
> >
- How do we deal with signed java applets, images and other
> > resources that
> > the client
may not have access to?
> >
> > Two approaches envisioned...
>
> 1. The aggregrator proxies the request from the client to the
> > remote portlet
>
> and proxies back the resource to the client.
>
> 2. The aggregrator caches the resource from the remote
> > portlet and serves it
> > to
the client.
> >
>
> - We need to come up with pros and cons of each approach.
> > - Also open to any other approaches that people may
come up with.
> >
>
>
> > URL Rewriting and Namespace
Encoding
> >
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > - go
over the following 3 scenarios, and come up with a list
> > of pros and
> > cons
> >
> > Scenarios:
> > 1. Aggregator sends a prefix w/ request and portlet
must use
> > it to do the
> > URL boundary demarcation. The aggregator then parses the
> > markup looking for
> > the prefix it provided.
> >
> > 2. All portlets use a predefined prefix
which is part of the spec to
> > demarcate URL
boundaries. The aggregator then parses the
> >
markup looking for
> > the well known
prefix.
> >
> > 3.
The aggregator automatically parses markup and
>
> heuristically determines
> > URL boundaries
and does the necessary rewriting automatically.
>
>
> > - Question: Will namespace encoding use
the same method as
> > URL encoding? Are
> > there any specific differences between the
two?
> > - Question: Should we mandate the
elements that should be
> > namespace
encoded
> > or leave it up to the portlet
developers to decide? Problem:
> > If we
mandate
> > the elements, then the spec will
need to be constantly
> > updated to
support
> > new technology and we would have to
explicitly cover a good
> portion of
> > existing scripting languages, markup languages
etc....
> >
> >
> > Leadership Succession
> > ~~~~~~~~~~~~~~~~~~~~~
> > - Due
to increasing time constraints and an ever tightening
> > schedule, I'm
> > going to have
to relinquish my duties as the leader of this
>
> sub-committee. I
> > fully intend to remain
an active member of this group and to
> > help
out as
> > much as I can, but I'm afraid I just
can't dedicate the time
> > necessary to
> > staying on top of all the discussion, making the
concall
> > agendas and leading
> > the discussion on the phone. We can, however, continue to use
> > Bowstreet's
>
> conference call facilities (which includes nice things such as
call
> > recordings to facilitate minute taking)
indefinitely.
> >
>
> - I'd like to select the new leader during this call and
> > transfer over the
> >
leadership of the calls starting with our subsequent
> conference call.
>
>
>
