webwork-devel Mailing List for WebWork (Page 40)
Brought to you by:
baldree,
rickardoberg
Menu
▾
▴
webwork-devel — WebWork development
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(316) |
Dec
(117) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(197) |
Feb
(229) |
Mar
(293) |
Apr
(177) |
May
(84) |
Jun
(40) |
Jul
(43) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Philipp M. <me...@o-...> - 2002-01-10 12:28:41
|
On Thu, Jan 10, 2002 at 12:58:18PM +0100, Rickard wrote: > Philipp Meier wrote: >=20 > >>>Portlets rely on the portlet container infrastructure accessible via t= he=20 > >>>Portlet API for functions like access to user profile information for= =20 > >>>the current user, > >> > >>WebWork Action *Aware interfaces. > > > >Nope, the aware interfaces won't give you a persistent storage of the > >users profile.=20 >=20 > What I meant was that the *Aware interface design allows you to plug=20 > these in easily. Although I'm not sure that's the best way to do that=20 > really. Yes, ww make this easy. But that's the idea behind a framework, isn't it. The main work is the api that is made available via the *Aware interfaces. Making this api standard is not strictly wrong but the JSR does not concentrate on this layer (user, persistence, preferences...) either. -billy. --=20 Philipp Meier o-matic GmbH Gesch=E4ftsf=FChrer Pfarrer-Wei=DF-Weg 16-18 Tel.: +49-(0)700-66284236 89077 Ulm |
|
From: Rickard <ri...@mi...> - 2002-01-10 11:58:49
|
Philipp Meier wrote: >>>Portlets rely on the portlet container infrastructure accessible via the >>>Portlet API for functions like access to user profile information for >>>the current user, >> >>WebWork Action *Aware interfaces. >> > > Nope, the aware interfaces won't give you a persistent storage of the > users profile. What I meant was that the *Aware interface design allows you to plug these in easily. Although I'm not sure that's the best way to do that really. >>>participation in the portal window >>>and action event model, access to web client information, >>> >>WebWork Action *Aware interfaces. > > Rickard, I think you got this one wrong. I'm not sure but I think by > accessing the "window object" the spec will give you a way to "roll-up", > close and rearrange the portlets on the page (like my.netscape.com > does). The event model will supplement this, I suppose by providing > listeners for these "window"-events. Ok, I see, yes that is different. >>>and a standard way of storing and retrieving >>>per-user/per-instance data persistently. >>> >>SessionAware.setSession(). >> > > Persistently! See above. Depends on your implementation of session ;-) > Rickard, I don't see much benefits in this JSR either, but webwork > alone won't do the job. I agree, it won't. But to a large extent it does. > Correct me if I'm wrong, it was you who did some > portlet developing a xpedio IIRC. I developed portal stuff using WebWork, yes. > I really love webwork and I don't like > this JSR but webwork is not the golden hammer. I agree. /Rickard -- Rickard Öberg |
|
From: Philipp M. <me...@o-...> - 2002-01-10 11:44:57
|
On Wed, Jan 09, 2002 at 10:50:09PM +0100, Rickard wrote: > >Portlets rely on the portlet container infrastructure accessible via the= =20 > >Portlet API for functions like access to user profile information for=20 > >the current user, >=20 >=20 > WebWork Action *Aware interfaces. Nope, the aware interfaces won't give you a persistent storage of the users profile. Although one could pass the reference to user manager into the action via ApplicationAware. > >access to the window object that represents the window=20 > >in which the portlet is displayed,=20 >=20 > What does this mean? >=20 > >participation in the portal window=20 > >and action event model, access to web client information,=20 >=20 > WebWork Action *Aware interfaces. Rickard, I think you got this one wrong. I'm not sure but I think by accessing the "window object" the spec will give you a way to "roll-up", close and rearrange the portlets on the page (like my.netscape.com does). The event model will supplement this, I suppose by providing listeners for these "window"-events. > >inter-portlet=20 > >messaging=20 >=20 > ActionFactory.getAction() I doubt this already does the jobs ;-)) Although I don't know what inter-portlet-messaging would be good for. > >and a standard way of storing and retrieving=20 > >per-user/per-instance data persistently. >=20 > SessionAware.setSession(). Persistently! See above. Rickard, I don't see much benefits in this JSR either, but webwork alone won't do the job. Correct me if I'm wrong, it was you who did some portlet developing a xpedio IIRC. I really love webwork and I don't like this JSR but webwork is not the golden hammer. -billy. --=20 Philipp Meier o-matic GmbH Gesch=E4ftsf=FChrer Pfarrer-Wei=DF-Weg 16-18 Tel.: +49-(0)700-66284236 89077 Ulm |
|
From: Matt B. <ma...@sm...> - 2002-01-10 01:56:34
|
thx ----- Original Message ----- From: "Doug Persons" <dou...@es...> To: <web...@li...> Sent: Wednesday, January 09, 2002 10:11 AM Subject: [Webwork-devel] JSP example bugs > In building the examples, I came across a few instances of old code in the > JSPs: > > \src\resources\web\events\autologin.jsp lines 4 & 5: > "property" should be "value" fixed > > \src\resources\web\helloworld\brief\login.jsp lines 7, 12 & 14: > "name" should be "value" (5 places) > fixed > \src\resources\web\i18n\price.jsp line 2: > "name" should be "value" (1 place) > fixed > And these two files are pretty much completely out of date: > \src\resources\web\template\chtml\controlheader.jsp > \src\resources\web\template\chtml\text.jsp > why? > > HTH, > Doug > > > _______________________________________________ > Webwork-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webwork-devel > > |
|
From: matt b. <ba...@us...> - 2002-01-10 01:55:36
|
Update of /cvsroot/webwork/webwork/src/resources/web/events In directory usw-pr-cvs1:/tmp/cvs-serv7116 Modified Files: autologin.jsp Log Message: update |
|
From: matt b. <ba...@us...> - 2002-01-10 01:55:10
|
Update of /cvsroot/webwork/webwork/src/resources/web/i18n In directory usw-pr-cvs1:/tmp/cvs-serv6989 Modified Files: price.jsp Log Message: update |
|
From: matt b. <ba...@us...> - 2002-01-10 01:54:42
|
Update of /cvsroot/webwork/webwork/src/resources/web/helloworld/brief In directory usw-pr-cvs1:/tmp/cvs-serv6832 Modified Files: login.jsp Log Message: update |
|
From: matt b. <ba...@us...> - 2002-01-10 01:30:15
|
Update of /cvsroot/webwork/webwork/src/docs In directory usw-pr-cvs1:/tmp/cvs-serv1779 Modified Files: index.xml Log Message: up revision to reflect the work to date |
|
From: matt b. <ba...@us...> - 2002-01-10 01:14:57
|
Update of /cvsroot/webwork/webwork/src/docs In directory usw-pr-cvs1:/tmp/cvs-serv30997 Modified Files: configuration.xml Log Message: updated for logger config change |
|
From: matt b. <ba...@us...> - 2002-01-10 01:14:25
|
Update of /cvsroot/webwork/webwork/src/resources/web In directory usw-pr-cvs1:/tmp/cvs-serv30903 Modified Files: index.jsp Log Message: misc update |
|
From: matt b. <ba...@us...> - 2002-01-10 01:14:11
|
Update of /cvsroot/webwork/webwork/src/resources/web/WEB-INF/classes In directory usw-pr-cvs1:/tmp/cvs-serv30864 Modified Files: views.properties Log Message: misc update |
|
From: matt b. <ba...@us...> - 2002-01-10 01:13:54
|
Update of /cvsroot/webwork/webwork/src/resources/web/WEB-INF/classes In directory usw-pr-cvs1:/tmp/cvs-serv30776 Modified Files: webwork.properties Added Files: log4j.properties log4j.xml Log Message: modified logging configuration |
|
From: matt b. <ba...@us...> - 2002-01-10 01:13:30
|
Update of /cvsroot/webwork/webwork/src/main/webwork In directory usw-pr-cvs1:/tmp/cvs-serv30671 Modified Files: default.properties Log Message: modified logging configuration |
|
From: matt b. <ba...@us...> - 2002-01-10 01:13:17
|
Update of /cvsroot/webwork/webwork/src/main/webwork/dispatcher In directory usw-pr-cvs1:/tmp/cvs-serv30632 Modified Files: ServletDispatcher.java Log Message: modified logging configuration |
|
From: matt b. <ba...@us...> - 2002-01-10 01:12:57
|
Update of /cvsroot/webwork/webwork/src/main/webwork/util In directory usw-pr-cvs1:/tmp/cvs-serv30560 Added Files: Logger.java Log Message: new |
|
From: Rickard <ri...@mi...> - 2002-01-09 22:17:57
|
If you want to see my generally ticked off reply to this on TheServerSide, go here: http://www.theserverside.com/home/thread.jsp?thread_id=11106 Gotta do some more meditation now and calm down... *sigh*.. /R |
|
From: Rickard <ri...@mi...> - 2002-01-09 22:15:18
|
Mike Cannon-Brookes wrote: > Couldn't have put it much better myself. AFAIK JetSpeed has more of a > presentation focus than webwork (despite all Rickards * = Actions ;)) - it's > more like a badly written webwork + sitemesh combination app. Exactly. I have only begun doing WebWork+SiteMesh stuff myself now that I'm rewriting TSS, but boy does it KICK ASS! I cannot see any other way that would be simpler than that. > There was some mention of a portal framework built ontop of webwork a while > back - perhaps this would make a good sample app? Depends on what you want in a "portal framework" I guess. Just using WebWork+SiteMesh solves a lot of problems right there, along with good design patterns of course. The goal is to OpenSource TheServerSide eventually, so I'm trying to build that in a frameworkish way. But it's damn tricky. And a lot of work... /Rickard -- Rickard Öberg |
|
From: Mike Cannon-B. <mi...@at...> - 2002-01-09 22:10:07
|
Couldn't have put it much better myself. AFAIK JetSpeed has more of a presentation focus than webwork (despite all Rickards * = Actions ;)) - it's more like a badly written webwork + sitemesh combination app. I looked again at the sample sites, 2 seem to be running the example app built from CVS, one is actually using JetSpeed but mainly as an aggregation tool for RSS feeds (which the webwork example does nicely too), and the other example app is actually now running slashcode (www.slashcode.com - the perl source behind slashdot). There was some mention of a portal framework built ontop of webwork a while back - perhaps this would make a good sample app? -mike On 9/1/02 4:50 PM, "Rickard" (ri...@mi...) penned the words: > Interesting. Thanks for the link! Comments inline. > > DeSouza, Edwin wrote: > >> The Portlet API specification defines an API for web application >> components that interact with and can be aggregated in web applications >> like portals. We refer to these components as portlets in the remainder >> of this text. > > > Sounds like WebWork actions. > > >> Portlets are web components like servlets, but have additional, special >> properties that allow them to easily plug into and run in enclosing web >> applications like portals. Portlets are designed to be aggregatable in >> the larger context of composite pages, e.g. multiple instances of the >> same portlet parameterized with different per-user, per-instance portlet >> data can coexist on the same portal page. Usually, many portlets are >> invoked in the course of handling a single request to aggregate their >> respective produced markup fragments in a page of markup. The markup >> fragments generated by portlets often need to contain links to trigger >> actions in the portlet, therefore URL-rewriting methods are required >> that allow portlets to transparently create links within the markup >> fragments they output, without needing to know how URLs are structured >> in the particular web application. > > > Still sounds like WebWork actions, with a touch of JSP taglibs to > simplify things (e.g. the "url" tag). > > >> Portlets rely on the portlet container infrastructure accessible via the >> Portlet API for functions like access to user profile information for >> the current user, > > > WebWork Action *Aware interfaces. > >> access to the window object that represents the window >> in which the portlet is displayed, > > > What does this mean? > >> participation in the portal window >> and action event model, access to web client information, > > > WebWork Action *Aware interfaces. > >> inter-portlet >> messaging > > > ActionFactory.getAction() > >> and a standard way of storing and retrieving >> per-user/per-instance data persistently. > > > SessionAware.setSession(). > >> The Portlet API provides standard interfaces for the functions mentioned >> above. The Portlet API extends the servlet programming model and defines >> a common base class and interfaces for portlets and tags for JSPs called >> by portlets, > > > I wonder how those tags will compare with those developed under the > Standard Taglib JSR. > >> cleanly separating portlets from the surrounding >> infrastructure so that portlets can run on different portal servers like >> servlets can run on different application servers. > > > Right. Just like WebWork actions can run in any servlet engine then. (or > Struts or whatever). > > >> The Portlet API specification shall evolve from the portlet concept as >> developed in the Apache JetSpeed Open Source project. > > > What an absolutely terrible idea since JetSpeed is badly mis-designed :-( > >> In many aspects, >> the Portlet API is an extension of the Servlet API, defining additional >> interfaces for portlet-specific functionality. In some other aspects, it >> restricts use of functions provided by the Servlet API to the subset >> that makes sense for portlets just producing aggregatable markup >> fragments and not having ownership of the entire page that displays >> them. For example, unlike servlets, portlets may not send errors or >> redirects as a response, this may only be done by the application that >> invokes and aggregates the portlets into a larger page. > > > Right, so making Portlets extensions of Servlets doesn't really work. > > >> Portlets can be grouped in Portlet Applications. Portlets in one portlet >> application can exchange messages via the Portlet API. Portlet >> Applications are packaged, distributed and deployed using WAR files that >> include portlet-related meta-information, utilizing existing Servlet >> infrastructure. > > > As is the case with WebWork, Struts, Maverick or whatever web framework > you fancy. > > >> The Portlet API shall be compatible with the Remote Portlet Web Services >> concept in the sense that portlets written to the Portlet API can act as >> local proxies in a portal server for remote portlet web services located >> on other servers and portlets written to the Portlet API can be wrapped >> into remote portlet web services. > > Like our ClientDispatcher stuff then. > > Overall, this sounds like an terrible idea. Basing a JSR on a specific > product like this, which happens to be generally bad, sounds stupid. > IMHO it is really better to have all of the frameworks that we have > today. I don't see the value in what they are proposing *as a spec*. In > four years perhaps, but not now. > > /Rickard Sent using the Entourage X Test Drive. |
|
From: Rickard <ri...@mi...> - 2002-01-09 21:50:10
|
Interesting. Thanks for the link! Comments inline. DeSouza, Edwin wrote: > The Portlet API specification defines an API for web application > components that interact with and can be aggregated in web applications > like portals. We refer to these components as portlets in the remainder > of this text. Sounds like WebWork actions. > Portlets are web components like servlets, but have additional, special > properties that allow them to easily plug into and run in enclosing web > applications like portals. Portlets are designed to be aggregatable in > the larger context of composite pages, e.g. multiple instances of the > same portlet parameterized with different per-user, per-instance portlet > data can coexist on the same portal page. Usually, many portlets are > invoked in the course of handling a single request to aggregate their > respective produced markup fragments in a page of markup. The markup > fragments generated by portlets often need to contain links to trigger > actions in the portlet, therefore URL-rewriting methods are required > that allow portlets to transparently create links within the markup > fragments they output, without needing to know how URLs are structured > in the particular web application. Still sounds like WebWork actions, with a touch of JSP taglibs to simplify things (e.g. the "url" tag). > Portlets rely on the portlet container infrastructure accessible via the > Portlet API for functions like access to user profile information for > the current user, WebWork Action *Aware interfaces. > access to the window object that represents the window > in which the portlet is displayed, What does this mean? > participation in the portal window > and action event model, access to web client information, WebWork Action *Aware interfaces. > inter-portlet > messaging ActionFactory.getAction() > and a standard way of storing and retrieving > per-user/per-instance data persistently. SessionAware.setSession(). > The Portlet API provides standard interfaces for the functions mentioned > above. The Portlet API extends the servlet programming model and defines > a common base class and interfaces for portlets and tags for JSPs called > by portlets, I wonder how those tags will compare with those developed under the Standard Taglib JSR. > cleanly separating portlets from the surrounding > infrastructure so that portlets can run on different portal servers like > servlets can run on different application servers. Right. Just like WebWork actions can run in any servlet engine then. (or Struts or whatever). > The Portlet API specification shall evolve from the portlet concept as > developed in the Apache JetSpeed Open Source project. What an absolutely terrible idea since JetSpeed is badly mis-designed :-( > In many aspects, > the Portlet API is an extension of the Servlet API, defining additional > interfaces for portlet-specific functionality. In some other aspects, it > restricts use of functions provided by the Servlet API to the subset > that makes sense for portlets just producing aggregatable markup > fragments and not having ownership of the entire page that displays > them. For example, unlike servlets, portlets may not send errors or > redirects as a response, this may only be done by the application that > invokes and aggregates the portlets into a larger page. Right, so making Portlets extensions of Servlets doesn't really work. > Portlets can be grouped in Portlet Applications. Portlets in one portlet > application can exchange messages via the Portlet API. Portlet > Applications are packaged, distributed and deployed using WAR files that > include portlet-related meta-information, utilizing existing Servlet > infrastructure. As is the case with WebWork, Struts, Maverick or whatever web framework you fancy. > The Portlet API shall be compatible with the Remote Portlet Web Services > concept in the sense that portlets written to the Portlet API can act as > local proxies in a portal server for remote portlet web services located > on other servers and portlets written to the Portlet API can be wrapped > into remote portlet web services. Like our ClientDispatcher stuff then. Overall, this sounds like an terrible idea. Basing a JSR on a specific product like this, which happens to be generally bad, sounds stupid. IMHO it is really better to have all of the frameworks that we have today. I don't see the value in what they are proposing *as a spec*. In four years perhaps, but not now. /Rickard -- Rickard Öberg |
|
From: Dave B. <db...@in...> - 2002-01-09 21:03:29
|
Did you actually look at the site. It looks like it's active to me. There's even some example sites online. Dave On Wednesday 09 January 2002 02:49 pm, you wrote: > I¹ll be interested to see how this turns out, especially as it's based on > JetSpeed which is a 'dead' Jakarta project (ie doesn't seem to have been > updated in ages, I can't find a single production site running it). Also it > used to have to have portlets coded in Java (as this seems to specify, it's > a portlet API like the servlet API). Anyone remember the days of coding > HTML in a servlet? ;) > > We'll wait and see I suppose. > > Back to your regularly scheduled WebWork programming! > > -mike > > On 9/1/02 2:41 PM, "DeSouza, Edwin" (ede...@ja...) penned the > > words: > > For more info: > > http://www.jcp.org/jsr/detail/162.jsp > > > > The Portlet API specification defines an API for web application > > components that interact with and can be aggregated in web applications > > like portals. We refer to these components as portlets in the remainder > > of this text. > > > > Portlets are web components like servlets, but have additional, special > > properties that allow them to easily plug into and run in enclosing web > > applications like portals. Portlets are designed to be aggregatable in > > the larger context of composite pages, e.g. multiple instances of the > > same portlet parameterized with different per-user, per-instance portlet > > data can coexist on the same portal page. Usually, many portlets are > > invoked in the course of handling a single request to aggregate their > > respective produced markup fragments in a page of markup. The markup > > fragments generated by portlets often need to contain links to trigger > > actions in the portlet, therefore URL-rewriting methods are required that > > allow portlets to transparently create links within the markup fragments > > they output, without needing to know how URLs are structured in the > > particular web application. > > > > Portlets rely on the portlet container infrastructure accessible via the > > Portlet API for functions like access to user profile information for the > > current user, access to the window object that represents the window in > > which the portlet is displayed, participation in the portal window and > > action event model, access to web client information, inter-portlet > > messaging and a standard way of storing and retrieving > > per-user/per-instance data persistently. > > > > The Portlet API provides standard interfaces for the functions mentioned > > above. The Portlet API extends the servlet programming model and defines > > a common base class and interfaces for portlets and tags for JSPs called > > by portlets, cleanly separating portlets from the surrounding > > infrastructure so that portlets can run on different portal servers like > > servlets can run on different application servers. > > > > The Portlet API specification shall evolve from the portlet concept as > > developed in the Apache JetSpeed Open Source project. In many aspects, > > the Portlet API is an extension of the Servlet API, defining additional > > interfaces for portlet-specific functionality. In some other aspects, it > > restricts use of functions provided by the Servlet API to the subset that > > makes sense for portlets just producing aggregatable markup fragments and > > not having ownership of the entire page that displays them. For example, > > unlike servlets, portlets may not send errors or redirects as a response, > > this may only be done by the application that invokes and aggregates the > > portlets into a larger page. > > > > Portlets can be grouped in Portlet Applications. Portlets in one portlet > > application can exchange messages via the Portlet API. Portlet > > Applications are packaged, distributed and deployed using WAR files that > > include portlet-related meta-information, utilizing existing Servlet > > infrastructure. > > > > The Portlet API shall be compatible with the Remote Portlet Web Services > > concept in the sense that portlets written to the Portlet API can act as > > local proxies in a portal server for remote portlet web services located > > on other servers and portlets written to the Portlet API can be wrapped > > into remote portlet web services. > > Sent using the Entourage X Test Drive. > > > _______________________________________________ > Webwork-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webwork-devel -- Dave Bryson |
|
From: Mike Cannon-B. <mi...@at...> - 2002-01-09 20:49:07
|
I=B9ll be interested to see how this turns out, especially as it's based on JetSpeed which is a 'dead' Jakarta project (ie doesn't seem to have been updated in ages, I can't find a single production site running it). Also it used to have to have portlets coded in Java (as this seems to specify, it's a portlet API like the servlet API). Anyone remember the days of coding HTM= L in a servlet? ;) We'll wait and see I suppose. Back to your regularly scheduled WebWork programming! -mike On 9/1/02 2:41 PM, "DeSouza, Edwin" (ede...@ja...) penned the words: > For more info:=20 > http://www.jcp.org/jsr/detail/162.jsp >=20 > The Portlet API specification defines an API for web application componen= ts > that interact with and can be aggregated in web applications like portals= . We > refer to these components as portlets in the remainder of this text. >=20 > Portlets are web components like servlets, but have additional, special > properties that allow them to easily plug into and run in enclosing web > applications like portals. Portlets are designed to be aggregatable in th= e > larger context of composite pages, e.g. multiple instances of the same po= rtlet > parameterized with different per-user, per-instance portlet data can coex= ist > on the same portal page. Usually, many portlets are invoked in the course= of > handling a single request to aggregate their respective produced markup > fragments in a page of markup. The markup fragments generated by portlets > often need to contain links to trigger actions in the portlet, therefore > URL-rewriting methods are required that allow portlets to transparently c= reate > links within the markup fragments they output, without needing to know ho= w > URLs are structured in the particular web application. >=20 > Portlets rely on the portlet container infrastructure accessible via the > Portlet API for functions like access to user profile information for the > current user, access to the window object that represents the window in w= hich > the portlet is displayed, participation in the portal window and action e= vent > model, access to web client information, inter-portlet messaging and a > standard way of storing and retrieving per-user/per-instance data > persistently. >=20 > The Portlet API provides standard interfaces for the functions mentioned > above. The Portlet API extends the servlet programming model and defines = a > common base class and interfaces for portlets and tags for JSPs called by > portlets, cleanly separating portlets from the surrounding infrastructure= so > that portlets can run on different portal servers like servlets can run o= n > different application servers. >=20 > The Portlet API specification shall evolve from the portlet concept as > developed in the Apache JetSpeed Open Source project. In many aspects, th= e > Portlet API is an extension of the Servlet API, defining additional inter= faces > for portlet-specific functionality. In some other aspects, it restricts u= se of > functions provided by the Servlet API to the subset that makes sense for > portlets just producing aggregatable markup fragments and not having owne= rship > of the entire page that displays them. For example, unlike servlets, port= lets > may not send errors or redirects as a response, this may only be done by = the > application that invokes and aggregates the portlets into a larger page. >=20 > Portlets can be grouped in Portlet Applications. Portlets in one portlet > application can exchange messages via the Portlet API. Portlet Applicatio= ns > are packaged, distributed and deployed using WAR files that include > portlet-related meta-information, utilizing existing Servlet infrastructu= re. >=20 > The Portlet API shall be compatible with the Remote Portlet Web Services > concept in the sense that portlets written to the Portlet API can act as = local > proxies in a portal server for remote portlet web services located on oth= er > servers and portlets written to the Portlet API can be wrapped into remot= e > portlet web services. >=20 Sent using the Entourage X Test Drive. |
|
From: DeSouza, E. <ede...@ja...> - 2002-01-09 19:41:54
|
For more info: http://www.jcp.org/jsr/detail/162.jsp The Portlet API specification defines an API for web application components that interact with and can be aggregated in web applications like portals. We refer to these components as portlets in the remainder of this text. Portlets are web components like servlets, but have additional, special properties that allow them to easily plug into and run in enclosing web applications like portals. Portlets are designed to be aggregatable in the larger context of composite pages, e.g. multiple instances of the same portlet parameterized with different per-user, per-instance portlet data can coexist on the same portal page. Usually, many portlets are invoked in the course of handling a single request to aggregate their respective produced markup fragments in a page of markup. The markup fragments generated by portlets often need to contain links to trigger actions in the portlet, therefore URL-rewriting methods are required that allow portlets to transparently create links within the markup fragments they output, without needing to know how URLs are structured in the particular web application. Portlets rely on the portlet container infrastructure accessible via the Portlet API for functions like access to user profile information for the current user, access to the window object that represents the window in which the portlet is displayed, participation in the portal window and action event model, access to web client information, inter-portlet messaging and a standard way of storing and retrieving per-user/per-instance data persistently. The Portlet API provides standard interfaces for the functions mentioned above. The Portlet API extends the servlet programming model and defines a common base class and interfaces for portlets and tags for JSPs called by portlets, cleanly separating portlets from the surrounding infrastructure so that portlets can run on different portal servers like servlets can run on different application servers. The Portlet API specification shall evolve from the portlet concept as developed in the Apache JetSpeed Open Source project. In many aspects, the Portlet API is an extension of the Servlet API, defining additional interfaces for portlet-specific functionality. In some other aspects, it restricts use of functions provided by the Servlet API to the subset that makes sense for portlets just producing aggregatable markup fragments and not having ownership of the entire page that displays them. For example, unlike servlets, portlets may not send errors or redirects as a response, this may only be done by the application that invokes and aggregates the portlets into a larger page. Portlets can be grouped in Portlet Applications. Portlets in one portlet application can exchange messages via the Portlet API. Portlet Applications are packaged, distributed and deployed using WAR files that include portlet-related meta-information, utilizing existing Servlet infrastructure. The Portlet API shall be compatible with the Remote Portlet Web Services concept in the sense that portlets written to the Portlet API can act as local proxies in a portal server for remote portlet web services located on other servers and portlets written to the Portlet API can be wrapped into remote portlet web services.=20 |
|
From: matt b. <mat...@ho...> - 2002-01-09 17:46:27
|
>Great, but you did do this by adding a conf parameter to >webwork.properties right? > >/Rickard yes. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com |
|
From: Rickard <ri...@mi...> - 2002-01-09 17:34:21
|
in...@sm... wrote: > Ok. I made the change so WW looks for a log4j configuration property that > points to a configuration file to configure itself. This can be a .properties > or .xml file or you can null it and it will assume appenders are already setup. > I will commit this tonight when I get a chance. Great, but you did do this by adding a conf parameter to webwork.properties right? /Rickard -- Rickard Öberg |
|
From: matt b. <mat...@ho...> - 2002-01-09 17:24:33
|
Ok. I made a change to WW so it now looks for a log4j configuration property using its normal configuration techniques. The property indicates a configuration file that can be a *.properties or *.xml file or you can null it and it will assume appenders are already setup. I will commit this tonight when I get a chance. I believe this should satisfy most needs. -Matt _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx |
34982 messages has been excluded from this view by a project administrator.
