At 17:22 01/30/01, Brian M. Long wrote:
>hey folks. i'm trying to put a hook into the jetspeed login process:
>
>i'd like to tweak the file responsible for responding to the login.html, to
>load a different outer frame for different users, but i can't tell where the
>login message is going. help?
>-bml
If you want to change the screen, implement you own loginaction and set the
screen in rundataaccording to the user group.
If you want a different Layout, you'll have to write your own
JetspeedJspLayout and check for the user group there.
ingo.
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, January 29, 2001 11:00 PM
> > To: JetSpeed
> > Subject: JetSpeed #385 - 01/29/01
> >
> >
> > JetSpeed #385 - Monday, January 29, 2001
> >
> > Jetspeed Daily Build Results - Sun, 28 Jan 2001 20:16:56 GMT
> > by "Jon S.Stevens" <[EMAIL PROTECTED]>
> > Re: JetspeedJspPage error
> > by "ingo schuster" <[EMAIL PROTECTED]>
> > RE: New Profiler
> > by "David Sean Taylor" <[EMAIL PROTECTED]>
> > Re: Service initialization (WAS: Couldn't process
> > URL:/ocs/local.ocs)
> > by "Santiago Gala" <[EMAIL PROTECTED]>
> > Re: Service initialization (WAS: Couldn't processURL:
> > /ocs/local.ocs)
> > by "Santiago Gala" <[EMAIL PROTECTED]>
> > Re: [long] Layout system, part 2: functional description
> > by <[EMAIL PROTECTED]>
> > Navigation inside Portlets
> > by "Mirko Buholzer" <[EMAIL PROTECTED]>
> > FW: JetspeedPersistenceService.java
> > by "Jon Stevens" <[EMAIL PROTECTED]>
> > Re: Service initialization (WAS: Couldn't processURL:
> > /ocs/local.ocs)
> > by "Jon Stevens" <[EMAIL PROTECTED]>
> > WebPagePortlet
> > by "Ingo Rammer" <[EMAIL PROTECTED]>
> > RE: JetspeedPersistenceService.java
> > by "David Sean Taylor" <[EMAIL PROTECTED]>
> > Re: Fwd: iCal
> > by "Jeff Prickett" <[EMAIL PROTECTED]>
> > RE: WebPagePortlet
> > by "David Sean Taylor" <[EMAIL PROTECTED]>
> > Re: WebPagePortlet
> > by "Jon Stevens" <[EMAIL PROTECTED]>
> > Re: JetspeedPersistenceService.java
> > by "Jon Stevens" <[EMAIL PROTECTED]>
> > AW: WebPagePortlet
> > by "Ingo Rammer" <[EMAIL PROTECTED]>
> > RE: WebPagePortlet
> > by "Craig Berry" <[EMAIL PROTECTED]>
> > RE: JetspeedPersistenceService.java
> > by "David Sean Taylor" <[EMAIL PROTECTED]>
> > Re: WebPagePortlet
> > by "Ingo Rammer" <[EMAIL PROTECTED]>
> > RE: WebPagePortlet
> > by "Craig Berry" <[EMAIL PROTECTED]>
> > Re: WebPagePortlet
> > by "Jon Stevens" <[EMAIL PROTECTED]>
> > Re: JetspeedJspPage error
> > by "Michael Sallman" <[EMAIL PROTECTED]>
> >
> >
> > ----------------------------------------------------------------------
> >
> > Subject: Jetspeed Daily Build Results - Sun, 28 Jan 2001 20:16:56 GMT
> > From: "Jon S.Stevens" <[EMAIL PROTECTED]>
> > Date: Mon, 29 Jan 2001 00:00:11 -0800 (PST)
> >
> >
> > ----------------------------------------------------
> > This email is autogenerated from the output from:
> > <http://oss.software.ibm.com/developerworks/opensource/jakarta>
> /proto/jetspeed.html>
> > ----------------------------------------------------
> >
> >
> > Buildfile: build\build.xml
> >
> > prepare:
> >
> > apis:
> > [java] -- Suppressing non fatal warnings.
> > [java] -- Suppressing non fatal warnings.
> > [java] -- Suppressing non fatal warnings.
> > [java] -- Suppressing non fatal warnings.
> >
> > core:
> > [mkdir] Created dir: D:\jakarta\jetspeed\bin
> > [mkdir] Created dir: D:\jakarta\jetspeed\bin\classes
> > [echo] Compiling in ../src/java and saving to ../bin/classes
> > [javac] Compiling 318 source files to
> > D:\jakarta\jetspeed\bin\classes
> > [javac] Note: 44 files use or override a deprecated API.
> > Recompile with "-deprecation" for details.
> > [javac] 1 warning
> >
> > dist:
> > [jar] Building jar: D:\jakarta\jetspeed\bin\Jetspeed.jar
> >
> > BUILD SUCCESSFUL
> >
> > Total time: 52 seconds
> >
> > ----------------------------------------------------------------------
> >
> > Subject: Re: JetspeedJspPage error
> > From: "ingo schuster" <[EMAIL PROTECTED]>
> > Date: Mon, 29 Jan 2001 09:22:09 +0100
> >
> > At 18:49 01/27/01, msallman wrote:
> > >Just an FYI,
> > >
> > >I just downloaded the latest stuff from cvs and built the war.
> > >I got this error accessing the home page:
> > >
> > >Horrible Exception: java.lang.ClassNotFoundException:
> > Requested Page not
> > >found: JetspeedJspPage at
> > >org.apache.turbine.modules.PageLoader.getInstance(PageLoader.
> > java:166)
> > >at org.apache.turbine.modules.PageLoader.exec(PageLoader.java:122) at
> > >etc......
> > >
> > >In TurbineResources.properties:
> > >page.default=JetspeedJspPage (which doesn't seem to exist (yet??))
> >
> > It does exist - however it's in a new directory. Try a clean
> > checkout or
> > make sure to checkout new directories during update.
> >
> > ingo.
> >
> >
> > >Using page.default=DefaultPage seems to work.
> > >
> > >
> > >Mike
> > >
> > >
> > >
> > >--
> > >--------------------------------------------------------------
> > >To subscribe: [EMAIL PROTECTED]
> > >To unsubscribe: [EMAIL PROTECTED]
> > >Search: <http://www.mail-archive.com/[email protected]/>
> > >List Help?: [EMAIL PROTECTED]
> >
> >
> > ----------------------------------------------------------------------
> >
> > Subject: RE: New Profiler
> > From: "David Sean Taylor" <[EMAIL PROTECTED]>
> > Date: Mon, 29 Jan 2001 00:56:47 -0800
> >
> > Santiago,
> >
> > I've checked in the new profiler integration for:
> > - Customizer
> > - Persistence Service
> >
> > I didn't write the ProfileFactory. No use writing it twice, since you
> > already have one.
> > Please check it in when you get a chance then I will update
> > everything to
> > use it.
> > Also please check in the SessionCachedProfile, I can begin
> > testing with it
> > this week.
> > Do you think the SessionCachedProfile should be the default jetspeed
> > profile?
> >
> > Im still working on the customizer integration, it seems to
> > work with HTML,
> > but not WML.
> > Anyway this will give you a chance to test it now.
> >
> > In order to test the new profiler, get the latest jr.p, and set
> > services.ProfileManager.enable to 'true'
> > It is currently set to false.
> > (this is only temporary until this stabilizes)
> >
> > services.ProfileManager.enable=true
> >
> >
> > Still some problems that Im aware of:
> >
> > -- when you create a new user, the Profiler needs to create a
> > directory for
> > that user
> > -- the goback button from 'fullscreen' mode on non-default or
> > group pages
> > goes back to the default page
> > -- WML does not store, and there may be a problem in general
> > with storing to
> > a file if its not there.
> >
> > i have some example of pages for groups and non-default
> > pages. i will try to
> > check those in later this week
> > i also have example of the persistence service.
> > It works fine, im storing the min/max session state of
> > portlets amongst
> > other specific stuff for my project, so it may not be useful to you,
> >
> > David
> >
> >
> > ----------------------------------------------------------------------
> >
> > Subject: Re: Service initialization (WAS: Couldn't process
> > URL:/ocs/local.ocs)
> > From: "Santiago Gala" <[EMAIL PROTECTED]>
> > Date: Mon, 29 Jan 2001 11:02:58 +0100
> >
> > Raphaël Luta escribió:
> > >
> > > [Rafal, I copy this message to you because I don't know if
> > you are on the
> > > Jetspeed list and this is Services related]
> > >
> > > Santiago Gala wrote:
> > > >
> > > > I think I found it. I will try to summarise, as an
> > opportunity to get
> > > > corrected if I make some error in my reasoning.
> > > >
> > > > The problem is with the sequence of initialization of services.
> > > >
> > > > Turbine provides two "rounds" of initialization for
> > services. In the
> > > > first round, services get called with a ServletConfig
> > object. Here we
> > > > perform most of our work. In the second round, services get called
> > > > without any argument.
> > > >
> > >
> > > That's quite accurate, most of our services perform early
> > initialization
> > > rather than late initialization.
> > >
> > > > The problem is that we don't implement the second round
> > init(). The
> > > > default behaviour in turbine for the secound round is to call
> > > > setInit(true). So, the problem is that a lot of times,
> > our services are
> > > > requested while they are being initialized. The result is
> > that turbine
> > > > will return the "half cooked" services to the thread
> > aking for them.
> > > >
> > > > I think the default behaviour in TurbineBaseService
> > init() is wrong. A
> > > > better default would be something like:
> > > >
> > > > init(Object), init(RunData) and
> > init(ServletConfig) do setInit(true)
> > > > (Turbine should guarantee that only one of these methods
> > is called for
> > > > each service)
> > > >
> > > > public void init() throws InitializationException {
> > > >
> > > > if(!getInit()) {
> > > > throw new InitializationException("Not yet inited");
> > > > }
> > > >
> > > > }
> > > >
> > > > As a default implementation it should not assume that any
> > service is to
> > > > be considered initialized when asked for, specially since
> > the default
> > > > first round init() does nothing. In the way I think it
> > should be, a
> > > > service that overrides early init takes responsibility of
> > setting init
> > > > to true, and one that does not override it gets inited
> > right. The way it
> > > > is now, a service should override both methods if it does any
> > > > initialization, to avoid race conditions like the ones we have.
> > > >
> > > > I have fixed the problems by implementing late init
> > methods in some
> > > > services (I will check for all and every service that has
> > initialization
> > > > process). This implementation waits for getInit()
> > returning true, while
> > > > printing messages every 100 milliseconds, to avoid either
> > having an
> > > > exception thrown or delivering a service that is "on its way".
> > > >
> > > > Some of the services implementation used synchronized in
> > the two init to
> > > > have mutual exclusion between both initializations. It
> > will not work,
> > > > except by locking turbine if some service is requested during
> > > > initialization of other service.
> > > >
> > >
> > > I agree that Turbine Services should probably make sure the
> > late init is
> > > called on an object when early init is complete, however
> > what you propose
> > > will not completely solve the specific RegistryManager
> > issue which, as far as
> > > I can understand, is that early init in RegistryManager has
> > an hidden dependency
> > > on RegistryManager through EntryFactory and PortletEntryNormalizer.
> > > Actually if you do block late init() on the RegistryManager
> > as should be, you
> > > have a deadlock...
> >
> >
> > I think I made it run, but I will study the issue, since I still get
> > some errors I cannot understand
> >
> > >
> > > So the *real* fix for this specific bug is to remove this
> > dependency, but digging
> > > deep into the JetspeedConfig/PortletRegistry is not
> > something I relish...
> > >
> >
> > I had to enter the "mud", and I'm full of it currently :-)
> >
> > I will start commiting after I check the changes in turbine
> > initialization.
> >
> > > I still agree with you that TurbineServices should ensure
> > that late init is always
> > > called when early init is complete to avoid race conditions
> > and highlight the kind
> > > of bugs we have
> > >
> > > --
> > > Raphaël Luta - [EMAIL PROTECTED]
> > > Vivendi Universal Networks - Services Manager / Paris
> > >
> > > --
> > > --------------------------------------------------------------
> > > To subscribe: [EMAIL PROTECTED]
> > > To unsubscribe: [EMAIL PROTECTED]
> > > Search:
> > <http://www.mail-archive.com/[email protected]/>
> > > List Help?: [EMAIL PROTECTED]
> >
> > ----------------------------------------------------------------------
> >
> > Subject: Re: Service initialization (WAS: Couldn't
> > processURL: /ocs/local.ocs)
> > From: "Santiago Gala" <[EMAIL PROTECTED]>
> > Date: Mon, 29 Jan 2001 11:07:06 +0100
> >
> > Jon Stevens escribió:
> > >
> > > Ok,
> > >
> > > Just so you know, I just got through with a few fairly
> > major changes to the
> > > way that Services works and it is much cleaner now. I also
> > tested a lot of
> > > the functionality so I know that things are working pretty well.
> > >
> > > on 1/28/01 1:13 PM, "Raphaël Luta"
> > <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > I agree that Turbine Services should probably make sure
> > the late init is
> > > > called on an object when early init is complete
> > >
> > > If you don't call setInit(true) in early init, then late
> > init() will be
> > > executed. I just tested this a few minutes ago and it works.
> > >
> > > > I still agree with you that TurbineServices should ensure
> > that late init is
> > > > always
> > > > called when early init is complete to avoid race
> > conditions and highlight the
> > > > kind
> > > > of bugs we have
> > >
> > > It is definitely called if getInit() returns false.
> > >
> > > In fact, here is the code...
> > >
> > > service = getServiceInstance(name);
> > > if(!service.getInit())
> > > {
> > > notice("Initializing service (late): " + name);
> > > service.init();
> > > }
> > >
> >
> > But what if the service is half way early initialization? That is the
> > problem we get. I will check your new code, to ensure there are no
> > problems with this.
> >
> > Our problem comes from the fact that early initialization of some
> > services is fairly slow, so race conditions are easy to happen.
> >
> >
> > > -jon
> > >
> > > --
> > > --------------------------------------------------------------
> > > To subscribe: [EMAIL PROTECTED]
> > > To unsubscribe: [EMAIL PROTECTED]
> > > Search:
> > <http://www.mail-archive.com/[email protected]/>
> > > List Help?: [EMAIL PROTECTED]
> >
> > ----------------------------------------------------------------------
> >
> > Subject: Re: [long] Layout system, part 2: functional description
> > From: <[EMAIL PROTECTED]>
> > Date: Mon, 29 Jan 2001 13:33:51 +0100
> >
> >
> >
> >
> > Raphael,
> >
> > thank you for taking the time to write this excellect description !
> >
> > See some first comments and questions below.
> >
> > Raphael Luta wrote:
> >
> > > [This document is a functional description of the new layout
> > > system. Comments, remarks, criticisms welcome...
> > > The actual implementation proposal will come after this
> > > document requirements are somewhat stabilized]
> > >
> > > Jetspeed layout system, part 2: Functional description
> > >
> > > Raphaël Luta <[EMAIL PROTECTED]>
> > >
> > > Definitions:
> > > ============
> > >
> > > 1. Portal configuration
> > > A portal configuration is a set of user properties, defined for a
> > > complete portal site, that is used by Jetspeed engine to
> > customize the
> > > portal site. A configuration will usually be media type dependent. A
> > given
> > > media type may be associated with several configurations
> > for the same
> > user
> > > profile.
> > >
> > > 2. Pane
> > > A pane is a customizable layout component which can be
> > included in the
> > > main portal templates. Each pane is responsible for the layout and
> > > rendering of its customized content elements.
> > >
> > > 3. Portlet
> > > A portlet is the base customizable content producing unit
> > in Jetspeed.
> > > The functional description will usually not separate the portlet, as
> > > portal-independent component model and the portlet, as part of the
> > > Jetspeed layout system.
> > > When such a distinction is necessary, the former will be
> > called "portlet"
> > > and the latter "screenlet".
> >
> > The meaning of the term "screenlet" cannot easily be found
> > out without the
> > definition. Perhaps we might use a more self-explaining term like
> > "portlet view" ?
> >
> > > Actors:
> > > =======
> > > This description may refer to the following actors:
> > >
> > > 1. Administrator:
> > > The administrator is the owner of the portal. He's responsible for
> > > designing the site templates and functionalities, configuring the
> > > initial properties files and defining the appropriate permissions.
> > > The administrator must understand the template language used by
> > > its site screens as well as the configuration files semantics.
> >
> > An administrator needs not necessarily be the owner of the entire
> > portal. There may be cases where a portal consists of a number of
> > independent portal instances. Each of these instances may have one
> > or more administrators.
> >
> > > 2. User:
> > > The user is a client of the site, which is assigned specific
> > > portal configurations. A user does not necessary refer to a
> > > physical entity (it may be an anonymous user, a group, etc...).
> > > No specific knowledge is required for the user.
> >
> > What does the last sentence mean ?
> >
> > > Portal site definition
> > > ======================
> > > A portal site is defined by the portal administrator who needs
> > > to configure different files :
> > >
> > > - screen templates (which may use any template language supported
> > > by Turbine) defining the different pages for the site.
> > > Each template may access a jetspeed toolbox object which,
> > > among other functionalities, will enable the administrator
> > > to include configurable panes in the site templates.
> >
> > What is the toolbox object ?
> >
> > > Example:
> > >
> > > index.vm:
> > > <table width="100%" cellspacing="0" cellpadding="0">
> > > <tr>
> > > <td valign="top">
> > > $jetspeed.Pane("home_main")
> > > </td>
> > > <td valign="top">
> > > $jetspeed.Pane("general_tools").Customize(false)
> > > $jetspeed.Pane("user_tools")
> > > </td>
> > > </tr>
> > > </table>
> > >
> > > [Note: the example markup proposed above is just used for
> > > descriptive purpose]
> > >
> > > When browsing this portal page, the named panes defintions
> > > will be loaded from the current user configuration.
> >
> > Is "$" used for macro-ivocation ?
> >
> > > - default portal configuration files
> > > These files describe the various panes available for use
> > within the
> > > site as well as the portlets included in these panes.
> > >
> > > example:
> > >
> > > default.psml
> > > <configuration>
> > > <panes>
> > > <pane name="home_main">
> > > <!-- responsible for managing the L&F (skin) of this pane -->
> > > <window-manager ref="MyYahooWM"/>
> > > <!-- responsible for the layout of the pane contents -->
> > > <layout-manager ref="MultiColumnManager">
> > > <column-max>3</column-max>
> > > </layout-manager>
> > > <!--
> > > <entry ref="rss_jetspeed">
> > > <column>0</column>
> > > </entry>
> > > <entry ref="rss_turbine">
> > > <column>0</column>
> > > </entry>
> > > <entry ref="rss_jakarta.apache.org">
> > > <column>1</column>
> > > </entry>
> > > </pane>
> > > <pane name="user_tools"/>
> > > <pane name="hobbies_left"/>
> > > <pane name="hobbies_right"/>
> > > </panes>
> > > <screenlets>
> > > <screenlet name="rss_jakarta.apache.org">
> > > <portlet ref="RSS"/>
> > > <url>http://jakarta.apache.org/overview.rss</url>
> > > <show-description>false</show-description>
> > > <max-items>5</max-items>
> > > </screenlet>
> > > <screenlet name="..."/>
> > > </screenlets>
> > > </configuration>
> >
> > I think it is a good idea to separate the layout/L&F from the
> > definition
> > of individual portlet views.
> >
> > > [Note; this markup is just for description purpose and may
> > be different
> > > than the one actually implemented]
> > >
> > > [Note: The information stored within these files may actually be
> > persusted
> > > in a relational SQL database or LDAP directory for complex sites
> > > requiring a high-performance, distributed backend. ]
> >
> > Yes, potentially, the database may contain a record for each
> > registered
> > portlet, portlet view, pane, ...
> >
> > I think we need a carefully designed interface for accessing this
> > information
> > which should be equally suited for persistence in databases
> > as well as XML
> > files. Below the interface, providers for database or
> > XML-file persistence
> > should be pluggable.
> >
> > > The administrator may have to configure several
> > configuration files for
> > > supporting various usage profiles of his site.
> > >
> > > - general layout registry
> > > This registry describes the available global layout
> > elements available.
> > > It mainly describes the window and layout managers available.
> > >
> > > example:
> > >
> > > <registry>
> > > <layout-manager name="MultiColumnManager">
> > >
> > <classname>org;apache.jetspeed.managers.VelocityManager</classname>
> > > <template>multi_column.vm</template>
> > > </layout-manager>
> > > <window-manager name="MyYahooWM">
> > >
> > <classname>org;apache.jetspeed.managers.VelocityManager</classname>
> > > <template type="html">my_yahoo.vm</template>
> > > <template type="wml">my_yahoo_wml.vm</template>
> > > </window-manager>
> > > </registry>
> > >
> > > [Note; this markup is just for description purpose and may
> > be different
> > > than the one actually implemented]
> > >
> > > - portlet registry
> > > The administrator may also need to modify the portlet registry in
> > > order to add specific portlets for his site.
> > > The portlet registry is part of the reusable component model of
> > > Jetspeed and will be described in the Portlet container
> > desxcription.
> > >
> > > Note 1:
> > > It's possible to emulate the current layout behavior by using the
> > > following template
> > >
> > > jetspeed1_2.vm
> > > $jetspeed.Pane("default")
> > >
> > > and defining as many configuration files as there are site
> > pages, all
> > > defining the "default" pane.
> > >
> > > Note 2:
> > > The new PSML syntax will have the following properties :
> > > - no recursive definitions: a pane element cannot contain
> > another pane
> > > - separation of contexts: the panes element will only
> > contain layout and
> > > skin properties, the entries element will only contain portlet
> > operational
> > > definitions.
> > >
> > > Managers
> > > ========
> > > 2 types of managers are used within the layout system:
> > >
> > > Window managers
> > > ---------------
> > > Their role is to decorate customizable elements with visual aids and
> > > links for accessing the portal operation for a given
> > element (for example
> > > customize, maximize, minimize, reemove, etc...).
> > > A window manager may be specified at the following place:
> > > - in a configuration element: it applies for all the portal
> > pages and all
> > > the panes unless overridden by a more specific manager.
> > > - in a pane element, it applies for all the pane elements
> > but not the
> > > pane itself
> > > - in a template, where it applies either for the complete
> > template when
> > > speficied stand-alone (overriding any pane specific manager) or
> > > applying only for a pane when specified as an argument to
> > this pane.
> > >
> > > Layout managers
> > > ---------------
> > > Layout managers are responsible for positioning the contents of
> > > a pane according to the layout properties attached to an entry and
> > > render the complete pane content.
> > >
> > > Portal operations
> > > =================
> > >
> > > Links
> > > -----
> > > In order to help building the site navigation between pages
> > or between
> > > portlets, panes, etc... The Jetspeed engine will also provide in the
> > > template context a link object which can be used to build links to
> > > other configurations, pages, panes, screenlets. This link may also
> > > specify a pre-defined portal action.
> > >
> > > Example:
> > >
> > > $jetspeed.link
> > > -> self-referential link
> > > $jetspeed.link.setConfiguration("work_html")
> > > -> display same template in another configuration
> > > $jetspeed.link.setConfiguration("work_html").setAction("Customize")
> > > -> customize the given configuration
> > > $jetspeed.link.setPane("user_tools").setAction("Minimize")
> > > -> minimize the user_tools pane in the current template
> > > $jetspeed.link.setPane("user_tools").setEntry(2).setAction("Info")
> > > -> display information on the third entry of the user_tools pane
> > >
> > > Customization
> > > -------------
> > > Portal customization will enable the user to do the
> > following operations:
> > > - create a new configuration
> > > - modify the properties of a pane
> > > - modify the contents of a pane (adding/removing entries or changing
> > > their layout properties)
> > > - modify the parameters of a given portlet
> > >
> > > If a user customizes any element, the portal will always implicitly
> > > create a user-specific configuration if it does not already exists.
> > > During a page layout, the user-specific configuration will always be
> > > searched first for a given pane or entry. If its doesn't contain the
> > pane,
> > > the portal will fallback to the default configuration.
> > > When a single entry is customized and the user specific
> > configuration
> > does
> > > contain the appropriate pane, the whole pane is copied
> > first in the user
> > > configuration.
> > >
> > > Multi-device operation
> > > ======================
> > > * It is anticipated that a given portal configuration will
> > usually only
> > > support one media-type (for example: default HTML conf,
> > default WML
> > conf,
> > > etc...).
> > > This behavior is dependent on the Profiler implementation.
> > > * A site page may or may not be media-type dependant,
> > depending on the
> > > administrator writing the page template
> > > * A pane definition is meda-type independant but may contain
> > media-dependant
> > > elements. In case some element doesn't handle a given
> > media-type when
> > > rendered, it is ignored.
> > > * For some media-type, the template rendered output may be
> > post-processed
> > > by an adapter which may modify the generated output.
> > > * If an adpater is configured for a given media-type, it
> > will also act
> > > as an URL cache and returns responses without content
> > regeneration.
> > >
> > > Example:
> > >
> > > * WML without adapter:
> > >
> > > user A - request home page --> RequestMapper (selects template)
> > > |
> > > V
> > > Profiler (selects configuration)
> > > |
> > > V
> > > user A <--- send response -- template rendering
> > >
> > > The rendered content may actually be unreadable by user A because of
> > > size of the aggregated result
> > >
> > > * WML with adapter:
> > >
> > > user A - request home page --> RequestMapper (selects adapter)
> > > |
> > > V
> > > WMLAdapter (selects template)
> > > |
> > > V
> > > Profiler (selects configuration)
> > > |
> > > V
> > > template rendering
> > > |
> > > V
> > > Adapter (parses result and fragment
> > > | result in smaller chunk)
> > > V
> > > user A <--- send response -- first result chunk
> > > user A - request chunk 2 --> RequestMapper (selects adapter)
> > > |
> > > V
> > > WMLAdapter (chunk required,
> > fetch from
> > cache)
> > > |
> > > V
> > > user A <--- send response -- second result chunk
> > >
> > >
> > > Items yet to be defined
> > > =======================
> > > * All the markup languages used for configuration need to
> > be completely
> > > specified
> >
> > I think we also have to specify a portal content model and an
> > OO API to
> > access it. Then we can define a default reperesentation of
> > that model in
> > an appropriate markup language.
> >
> > > * The jetspeed toolbox available whithin templates must be fully
> > > described
> >
> > Can you give examples of the functionality you would envision in the
> > toolbox ?
> >
> > > * Should we allow the use of variables as entry parameters
> > within pane
> > > definitions ?
> >
> > Can you give examples ?
> >
> > > * Are there any specific requirements for handling form
> > submissions ?
> >
> > I think we need a generic mechanism transparent to portlet
> > programmers that
> > assures that form submissions are routed to the right
> > destination (e.g.
> > portlet)
> > through the portlet container.
> >
> > >
> > > --
> > > Raphaël Luta - [EMAIL PROTECTED]
> > > Vivendi Universal Networks - Services Manager / Paris
> > >
> >
> >
> >
> > ----------------------------------------------------------------------
> >
> > Subject: Navigation inside Portlets
> > From: "Mirko Buholzer" <[EMAIL PROTECTED]>
> > Date: Mon, 29 Jan 2001 15:06:39 +0100 (MET)
> >
> > Does some one have an example dispatch routine for enabling navigation
> > inside Portlets.
> >
> > How do you get the target URL to post any data from the portlet?
> >
> > Kind regards
> > Mirko Buholzer
> >
> > --
> > Sent through GMX FreeMail - http://www.gmx.net
> >
> >
> > ----------------------------------------------------------------------
> >
> > Subject: FW: JetspeedPersistenceService.java
> > From: "Jon Stevens" <[EMAIL PROTECTED]>
> > Date: Mon, 29 Jan 2001 10:21:41 -0800
> >
> > I just want to make sure that you guys aren't caching RunData
> > objects...that
> > is BAD BAD BAD...those objects should *never* persist longer than the
> > current request.
> >
> > Also, I *hate* it when people name their variables with "iFoo" or
> > "aFoo"...this is Java, not C. There are no global variables
> > in Java and it
> > is trivial to tell which one you are dealing with within a
> > Class and placing
> > naming conventions on the variables like that just make things more
> > confusing...not less...especially if the rest of the code
> > base doesn't look
> > anything like that.
> >
> > :-)
> >
> > -jon
> >
> >
> > public void store ()
> > {
> > // store page by page (and let's hope that no
> > exception occurs
> > // -> missing transaction integrity is a major concern here!
> >
> > for (Enumeration e = getPages (); e.hasMoreElements (); )
> > {
> > Page page = (Page) e.nextElement ();
> >
> > page.store (iRunData);
> > }
> > }
> >
> >
> >
> > ----------------------------------------------------------------------
> >
> > Subject: Re: Service initialization (WAS: Couldn't
> > processURL: /ocs/local.ocs)
> > From: "Jon Stevens" <[EMAIL PROTECTED]>
> > Date: Mon, 29 Jan 2001 10:46:38 -0800
> >
> > on 1/29/01 2:07 AM, "Santiago Gala" <[EMAIL PROTECTED]> wrote:
> >
> > > But what if the service is half way early initialization?
> > That is the
> > > problem we get. I will check your new code, to ensure there are no
> > > problems with this.
> > >
> > > Our problem comes from the fact that early initialization of some
> > > services is fairly slow, so race conditions are easy to happen.
> >
> > The start of the initialization services should be done in a
> > synchronized
> > block to prevent race conditions. Look at Turbine.java's code. :-)
> >
> > Also, when you reply to messages, please just include the
> > relevant portions
> > and not the entire email...
> >
> > thanks,
> >
> > -jon
> >
> >
> > ----------------------------------------------------------------------
> >
> > Subject: WebPagePortlet
> > From: "Ingo Rammer" <[EMAIL PROTECTED]>
> > Date: Mon, 29 Jan 2001 20:19:49 +0100
> >
> > Hi,
> >
> > As I'll be finished in some hours I just wanted to know, whom
> > I should send
> > my 2 files for the WebPagePortlet to?
> >
> > [Features:
> >
> > * Rewriting of <A HREFs, <IMG SRCs, <FORMs (self-referencing
> > forms as well)
> > * Removal of <HEAD>, <SCRIPT>, <META>, <STYLE>
> > * Removal of <OBJECT>, <EMBED>, <APPLET>
> >
> > ... and the code is quite readable as well ;)
> >
> > Tested under jdk 1.3 and jdk 1.2.2 using W2K; no external
> > dependencies in
> > any form ... not much resemblance with the two portlet's
> > which got sent to
> > me, because one had another external dependency and the other did the
> > HTML-parsing/rewriting manually, even though there's some
> > support for this
> > in the java-language.
> > ]
> >
> > Thanks for the information,
> > Ingo
> >
> > ----------------------------------------------------------------------
> >
> > Subject: RE: JetspeedPersistenceService.java
> > From: "David Sean Taylor" <[EMAIL PROTECTED]>
> > Date: Mon, 29 Jan 2001 11:40:23 -0800
> >
> > Wow, the wrath of Jon, bummer...
> >
> > Let me *try* to defend myself:
> >
> > In creating JetspeedPersistenceService.java, I copied
> > PersistenceServiceImpl.java.
> > The code is basically the same, but the
> > JetspeedPersistenceService uses a
> > newer profiler.
> > I didn't want to modify PersistenceServiceImpl.java, since
> > others may still
> > want to use the old profiler. Thus I created a new service impl.
> >
> > Let me state that I don't use "iFoo" conventions, please
> > reference my other
> > commits.
> > I know you can argue that I *now* use "iFoo" conventions
> > since I was too
> > lazy, I rather believe I was too polite, so you do have a point there.
> > I will change the variable names.
> >
> > I have also brought up the fact on this mailing list that
> > invocations of the
> > Persistence Service required multiple 'new' persistence services per
> > request.
> > So this means that since the lifetime of the service object
> > is only for one
> > request, its then safe to 'cache' the RunData, since the
> > service object will
> > be gone after the request.
> >
> > This is counter to how I believe services should work, again
> > I've discussed
> > this on the list.
> > >From a performance and lifecycle mgt perspective, there are
> > also issues....
> >
> > In defense of the authors, I believe that the
> > PersistenceService was written
> > as a 'temporary solution', since the underlying classes used
> > by it i.e. the
> > PortletSet and PSMLManager are due for some major overhauls.
> > In that spirit,
> > I left the service as is since it works for now.
> >
> > Im all for rewriting the Persistence Service to be a Turbine
> > Service. But
> > when I suggested that, it was argued that we are considering
> > our own service
> > model for the 'Portal API' that isn't dependent on anything else. The
> > committers to this service will be able to describe this
> > more, but they are
> > in Europe so it probably won't be til tomorrow.
> >
> > Damn, now I suppose that everytime you see my name, you will
> > think "iFoo",
> > or even worse, the "iFoo Propagator".
> > Where's there a corner I can hide in....
> >
> > -- iFoo
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of Jon Stevens
> > > Sent: Monday, January 29, 2001 10:22 AM
> > > To: jetspeed
> > > Subject: FW: JetspeedPersistenceService.java
> > >
> > >
> > > I just want to make sure that you guys aren't caching RunData
> > > objects...that
> > > is BAD BAD BAD...those objects should *never* persist
> > longer than the
> > > current request.
> > >
> > > Also, I *hate* it when people name their variables with "iFoo" or
> > > "aFoo"...this is Java, not C. There are no global variables
> > in Java and it
> > > is trivial to tell which one you are dealing with within a Class
> > > and placing
> > > naming conventions on the variables like that just make things more
> > > confusing...not less...especially if the rest of the code base
> > > doesn't look
> > > anything like that.
> > >
> > > :-)
> > >
> > > -jon
> > >
> > >
> > > public void store ()
> > > {
> > > // store page by page (and let's hope that no
> > exception occurs
> > > // -> missing transaction integrity is a major
> > concern here!
> > >
> > > for (Enumeration e = getPages (); e.hasMoreElements (); )
> > > {
> > > Page page = (Page) e.nextElement ();
> > >
> > > page.store (iRunData);
> > > }
> > > }
> > >
> > >
> > >
> > >
> > > --
> > > --------------------------------------------------------------
> > > To subscribe: [EMAIL PROTECTED]
> > > To unsubscribe: [EMAIL PROTECTED]
> > > Search:
> > <http://www.mail-archive.com/[email protected]/>
> > > List Help?: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > ----------------------------------------------------------------------
> >
> > Subject: Re: Fwd: iCal
> > From: "Jeff Prickett" <[EMAIL PROTECTED]>
> > Date: Mon, 29 Jan 2001 11:43:40 -0800 (PST)
> >
> >
> >
> > On Fri, 26 Jan 2001, Santiago Gala wrote:
> >
> > > ingo schuster escribió:
> > > >
> > > > I don't know much about iCalender. Anybody else?
> > > > ingo.
> > > >
> > > > >From: Thierry Janaudy <[EMAIL PROTECTED]>
> > > > >To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> > > > >Subject: iCal
> > > > >Date: Wed, 24 Jan 2001 18:21:34 -0000
> > > > >X-Mailer: Internet Mail Service (5.5.2650.21)
> > > > >
> > > > >Hello,
> > > > >
> > > > >I am interested in your iCal implementation.
> > > > >Can you please tell me its status, and if it has
> > > > >been tested agaisnt iPortal, Micrsoft Exchange server?
> > >
> > > The only thing I know is that updates show cvs activity from time to
> > > time, so it is not stopped. See a previous post by Raphael
> > on the issue.
> > >
> >
> > Hello,
> > I am the person responsible for the iCalendar implementation.
> > Its current
> > status is.
> >
> > It saves Event and To Do objects in the database. As well as
> > attendees and
> > categories. There may be some more functionality which is largely
> > untested.
> >
> > This includes
> >
> > 1. writing an iCalendar stream minus long line folding.
> > 2. reading an iCalendar property from a stream after it has
> > been folded.
> >
> > An overhaul of the Base Peer classes is in order as well as
> > an overhaul
> > of the private and protected methods of the iCalendar
> > business objects.
> >
> > Right now I dont have a lot of flexibility with the overhaul
> > as my company
> > is trying to wrap up a product on this current version of the
> > apache code.
> >
> > If any one is willing to help reengineer the backend please
> > email me. I
> > have some ideas on how we can extend turbines auto generated
> > peers to work
> > with iCalendar.
> >
> > Just dont have the time :(.
> >
> >
> >
> > Jeff Prickett
> >
> >
> > ----------------------------------------------------------------------
> >
> > Subject: RE: WebPagePortlet
> > From: "David Sean Taylor" <[EMAIL PROTECTED]>
> > Date: Mon, 29 Jan 2001 12:35:39 -0800
> >
> > Ingo,
> >
> > I'd be glad to test it out.
> > Include the source in an email to the list, so that others
> > can test it too.
> >
> > David
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of Ingo Rammer
> > > Sent: Monday, January 29, 2001 11:20 AM
> > > To: '[EMAIL PROTECTED]'
> > > Subject: WebPagePortlet
> > >
> > >
> > > Hi,
> > >
> > > As I'll be finished in some hours I just wanted to know, whom I
> > > should send
> > > my 2 files for the WebPagePortlet to?
> > >
> > > [Features:
> > >
> > > * Rewriting of <A HREFs, <IMG SRCs, <FORMs (self-referencing
> > > forms as well)
> > > * Removal of <HEAD>, <SCRIPT>, <META>, <STYLE>
> > > * Removal of <OBJECT>, <EMBED>, <APPLET>
> > >
> > > ... and the code is quite readable as well ;)
> > >
> > > Tested under jdk 1.3 and jdk 1.2.2 using W2K; no external
> > dependencies in
> > > any form ... not much resemblance with the two portlet's
> > which got sent to
> > > me, because one had another external dependency and the
> > other did the
> > > HTML-parsing/rewriting manually, even though there's some
> > support for this
> > > in the java-language.
> > > ]
> > >
> > > Thanks for the information,
> > > Ingo
> > >
> > >
> > > --
> > > --------------------------------------------------------------
> > > To subscribe: [EMAIL PROTECTED]
> > > To unsubscribe: [EMAIL PROTECTED]
> > > Search:
> > <http://www.mail-archive.com/[email protected]/>
> > > List Help?: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > ----------------------------------------------------------------------
> >
> > Subject: Re: WebPagePortlet
> > From: "Jon Stevens" <[EMAIL PROTECTED]>
> > Date: Mon, 29 Jan 2001 13:33:26 -0800
> >
> > on 1/29/01 11:19 AM, "Ingo Rammer" <[EMAIL PROTECTED]> wrote:
> >
> > > * Rewriting of <A HREFs, <IMG SRCs, <FORMs
> > (self-referencing forms as well)
> > > * Removal of <HEAD>, <SCRIPT>, <META>, <STYLE>
> > > * Removal of <OBJECT>, <EMBED>, <APPLET>
> >
> > Not sure what this is for, but if it is for security, you
> > shouldn't specify
> > what to *remove* but what to *keep*.
> >
> > -jon
> >
> >
> > ----------------------------------------------------------------------
> >
> > Subject: Re: JetspeedPersistenceService.java
> > From: "Jon Stevens" <[EMAIL PROTECTED]>
> > Date: Mon, 29 Jan 2001 13:39:58 -0800
> >
> > on 1/29/01 11:40 AM, "David Sean Taylor"
> > <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Wow, the wrath of Jon, bummer...
> >
> > Not wrath. I put a friggen :-) at the end of the email. Sigh.
> >
> > :-(
> >
> > > Let me *try* to defend myself:
> > >
> > > In creating JetspeedPersistenceService.java, I copied
> > > PersistenceServiceImpl.java.
> > > The code is basically the same, but the
> > JetspeedPersistenceService uses a
> > > newer profiler.
> > > I didn't want to modify PersistenceServiceImpl.java, since
> > others may still
> > > want to use the old profiler. Thus I created a new service impl.
> >
> > Not a problem.
> >
> > > I will change the variable names.
> >
> > Great!
> >
> > > I have also brought up the fact on this mailing list that
> > invocations of the
> > > Persistence Service required multiple 'new' persistence
> > services per
> > > request.
> > > So this means that since the lifetime of the service object
> > is only for one
> > > request, its then safe to 'cache' the RunData, since the
> > service object will
> > > be gone after the request.
> >
> > Ok. I was just checking.
> >
> > > This is counter to how I believe services should work,
> > again I've discussed
> > > this on the list.
> >
> > Then maybe implement it differently?
> >
> > > In defense of the authors, I believe that the
> > PersistenceService was written
> > > as a 'temporary solution', since the underlying classes
> > used by it i.e. the
> > > PortletSet and PSMLManager are due for some major
> > overhauls. In that spirit,
> > > I left the service as is since it works for now.
> > >
> > > Im all for rewriting the Persistence Service to be a
> > Turbine Service. But
> > > when I suggested that, it was argued that we are
> > considering our own service
> > > model for the 'Portal API' that isn't dependent on anything
> > else. The
> > > committers to this service will be able to describe this
> > more, but they are
> > > in Europe so it probably won't be til tomorrow.
> >
> > Ok, I'm *strongly* -1 on any more Services frameworks being built.
> >
> > Please look at the BaseService class in Turbine. It is a very clean
> > framework for building Services. One could easily build a
> > PortletService on
> > top of BaseService....instead of having it built on top of
> > TurbineServices.
> >
> > If you look at the BaseService, it does nothing more than
> > import java.util.
> > There is zero dependencies on any of the rest of the system.
> >
> > > Damn, now I suppose that everytime you see my name, you
> > will think "iFoo",
> > > or even worse, the "iFoo Propagator".
> > > Where's there a corner I can hide in....
> >
> > Oh, don't say immature things when someone simply asks why
> > things are being
> > done the way that things are being done. This project has a
> > long history of
> > not doing things properly...work to fix it, not to make it worse.
> >
> > thanks,
> >
> > -jon
> >
> >
> > ----------------------------------------------------------------------
> >
> > Subject: AW: WebPagePortlet
> > From: "Ingo Rammer" <[EMAIL PROTECTED]>
> > Date: Mon, 29 Jan 2001 23:08:51 +0100
> >
> > Hi,
> >
> > I'd rather send it to someone who could check it into cvs, so
> > that in case
> > of bugs we don't have too many different versions floating around.
> >
> > Simply checking it in, without changing the config-files
> > would not break
> > anything ... even if it wouldn't work at all ;))
> >
> > Ingo
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: David Sean Taylor [mailto:[EMAIL PROTECTED]]
> > > Gesendet: Montag, 29. Jänner 2001 21:36
> > > An: JetSpeed
> > > Betreff: RE: WebPagePortlet
> > >
> > >
> > > Ingo,
> > >
> > > I'd be glad to test it out.
> > > Include the source in an email to the list, so that others
> > > can test it too.
> > >
> > > David
> >
> > ----------------------------------------------------------------------
> >
> > Subject: RE: WebPagePortlet
> > From: "Craig Berry" <[EMAIL PROTECTED]>
> > Date: Mon, 29 Jan 2001 14:39:42 -0800
> >
> > > From: Jon Stevens [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, January 29, 2001 1:33 PM
> > >
> > > Not sure what this is for, but if it is for security, you
> > > shouldn't specify
> > > what to *remove* but what to *keep*.
> >
> > I'd imagine it's part of the general "scrub it to fit in a td
> > cell" process,
> > though why you'd have to strip objects and applets to get
> > there is a bit
> > confusing.
> >
> > I'm still not quite sure I understand the niche
> > WebPagePortlet is trying to
> > fill. If you're grabbing a page you control, why not use
> > whatever process
> > drives its content to drive a separate portlet content source
> > (rss, for
> > example) as well? And if you're grabbing a page you don't
> > control, what are
> > the odds that a page designed for at least a medium-sized
> > window is going to
> > scrunch into a portlet cell without looking like a complete
> > mess, or making
> > a mess of the rest of the portal layout?
> >
> > What am I missing? What's this thing for?
> >
> > --
> > Craig Berry - (310) 570-4140
> > VP Technology
> > GlueCode
> > 1452 Second St
> > Santa Monica CA 90401
> >
> >
> > ----------------------------------------------------------------------
> >
> > Subject: RE: JetspeedPersistenceService.java
> > From: "David Sean Taylor" <[EMAIL PROTECTED]>
> > Date: Mon, 29 Jan 2001 14:50:55 -0800
> >
> > >
> > > Then maybe implement it differently?
> > ...
> > > Ok, I'm *strongly* -1 on any more Services frameworks being built.
> > ...
> > > If you look at the BaseService, it does nothing more than import
> > > java.util.
> > > There is zero dependencies on any of the rest of the system.
> >
> > absolutely
> > We need to agree on a common base service.
> > This discussion will help make that happen.
> > Any arguments for BaseService or a portal api-based portal.service are
> > welcome
> >
> >
> >
> > ----------------------------------------------------------------------
> >
> > Subject: Re: WebPagePortlet
> > From: "Ingo Rammer" <[EMAIL PROTECTED]>
> > Date: Tue, 30 Jan 2001 00:26:34 +0100
> >
> > > Von: Craig Berry [mailto:[EMAIL PROTECTED]]
> > > Gesendet: Montag, 29. Jänner 2001 23:40
> > > >
> > > > Not sure what this is for, but if it is for security, you
> > > > shouldn't specify
> > > > what to *remove* but what to *keep*.
> > >
> > > I'd imagine it's part of the general "scrub it to fit in a td
> > > cell" process,
> > > though why you'd have to strip objects and applets to get
> > > there is a bit
> > > confusing.
> >
> > On one hand it's just for keeping the layout consistent
> > (which means, there
> > shouldn't be another <STYLE>-Tag in). On the other hand, a <META
> > http-equiv="REDIRECT... -Tag wouldn't be nice in a portal anyway ...
> >
> > Every "scrubbing"-feature can be turned of for any page you
> > want to include
> > in the portal. (The only thing that can't be switched is the automatic
> > opening/closing of missing tags ... so that a included
> > "</table>" without
> > corresponding "<table>" wouldn't mess up with your layout.
> >
> > > I'm still not quite sure I understand the niche
> > > WebPagePortlet is trying to
> > > fill. If you're grabbing a page you control, why not use
> > > whatever process
> > > drives its content to drive a separate portlet content source
> > > (rss, for
> > > example) as well? And if you're grabbing a page you don't
> > > control, what are
> > > the odds that a page designed for at least a medium-sized
> > > window is going to
> > > scrunch into a portlet cell without looking like a complete
> > > mess, or making
> > > a mess of the rest of the portal layout?
> >
> > It's mainly, because (at least here, I don't know about the
> > rest of the
> > world yet ;) ) some pages will be maintained by independent
> > people/departments where you cannot force them to use anything but the
> > corporate/departmental standard tool for website-design
> > (which is in our
> > case f.e. FrontPage). I nevertheless want to integrate some
> > information from
> > their pages in a portal.
> >
> > > What am I missing? What's this thing for?
> >
> > It was mainly because on one hand three people (including me) already
> > started developing something like this and on the other hand,
> > I needed it
> > for said integration of already exisiting information on
> > different project's
> > pages which are maintained seperately.
> >
> > Ingo
> >
> > ----------------------------------------------------------------------
> >
> > Subject: RE: WebPagePortlet
> > From: "Craig Berry" <[EMAIL PROTECTED]>
> > Date: Mon, 29 Jan 2001 16:04:38 -0800
> >
> > > From: Ingo Rammer [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, January 29, 2001 3:27 PM
> > >
> > > Every "scrubbing"-feature can be turned of for any page you
> > > want to include
> > > in the portal. (The only thing that can't be switched is
> > the automatic
> > > opening/closing of missing tags ... so that a included
> > > "</table>" without
> > > corresponding "<table>" wouldn't mess up with your layout.
> >
> > Yow, hadn't even thought about all the mischief there...
> >
> > > > I'm still not quite sure I understand the niche
> > > > WebPagePortlet is trying to fill.
> > >
> > > It's mainly, because (at least here, I don't know about the
> > > rest of the
> > > world yet ;) ) some pages will be maintained by independent
> > > people/departments where you cannot force them to use
> > anything but the
> > > corporate/departmental standard tool for website-design
> > > (which is in our
> > > case f.e. FrontPage). I nevertheless want to integrate some
> > > information from their pages in a portal.
> >
> > Okay, it's making more sense now. A combination of lack of
> > direct control
> > with predictability of form fits the bill pretty well.
> >
> > --
> > Craig Berry - (310) 570-4140
> > VP Technology
> > GlueCode
> > 1452 Second St
> > Santa Monica CA 90401
> >
> >
> > ----------------------------------------------------------------------
> >
> > Subject: Re: WebPagePortlet
> > From: "Jon Stevens" <[EMAIL PROTECTED]>
> > Date: Mon, 29 Jan 2001 16:37:32 -0800
> >
> > on 1/29/01 3:26 PM, "Ingo Rammer" <[EMAIL PROTECTED]> wrote:
> >
> > > On one hand it's just for keeping the layout consistent
> > (which means, there
> > > shouldn't be another <STYLE>-Tag in). On the other hand, a <META
> > > http-equiv="REDIRECT... -Tag wouldn't be nice in a portal anyway ...
> > >
> > > Every "scrubbing"-feature can be turned of for any page you
> > want to include
> > > in the portal. (The only thing that can't be switched is
> > the automatic
> > > opening/closing of missing tags ... so that a included
> > "</table>" without
> > > corresponding "<table>" wouldn't mess up with your layout.
> >
> > A better methodology for this is to simply remove the tags
> > that you don't
> > know about and keep the ones that you want...this can be done
> > with a regular
> > expression. I suggest that you do it this way. :-)
> >
> > -jon
> >
> >
> > ----------------------------------------------------------------------
> >
> > Subject: Re: JetspeedJspPage error
> > From: "Michael Sallman" <[EMAIL PROTECTED]>
> > Date: Mon, 29 Jan 2001 18:50:01 -0600
> >
> > Ingo,
> >
> > Thanks. I just did a fresh checkout and everything seems ok.
> > I guess I'll have to read up some more on CVS :-)
> >
> > Mike
> >
> > ingo schuster wrote:
> >
> > >
> > > It does exist - however it's in a new directory. Try a
> > clean checkout or
> > > make sure to checkout new directories during update.
> > >
> > > ingo.
> > >
> >
> >
> > ----------------------------------------------------------------------
> > End of JetSpeed
> >
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Search: <http://www.mail-archive.com/[email protected]/>
> > List Help?: [EMAIL PROTECTED]
> >
>
>
>
>--
>--------------------------------------------------------------
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>Search: <http://www.mail-archive.com/[email protected]/>
>List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
