There are a number of good client-side technologies that can be used.
The problem is that they work best and sometimes only if the DOM stays
loaded. If pages are constantly being reloaded this ends up destroying
and recreating the DOM.
Gerry Reno
--- [EMAIL PROTECTED] wrote:
> > -Original
> -Original Message-
> From: Weaver, Scott [mailto:[EMAIL PROTECTED]
>
> Can svg do as much as Flash can, like Flash Forms, etc? I
> ask this because I know very little about the current state of svg.
>
This probably starts to get a little far afield for the Jetspeed list, but
you ough
Right on the money, Jasen.
Gerry Reno
--- [EMAIL PROTECTED] wrote:
> I know nothing about JMX (Java Management
> Extensions)(http://java.sun.com/products/JavaManagement/) other than
> what I
> just read from the first paragraph of Sun's site. However, I do know
> a bit
> about SVG, and IMHO it w
Jasen,
It is possible to do it that way certainly.
Gerry Reno
--- [EMAIL PROTECTED] wrote:
> > -Original Message-
> > From: Jan Grant [mailto:[EMAIL PROTECTED]
> >
> > (I personally think/hope the pre-generation of images argument will
> > hopefully become less of a kicker as browser s
Joachim,
Ok, I looked at the links that you sent to me. They are not ruling
out javascript, what this seems to be talking about is being sure that
you have a fallback mechanism in case scripting is not supported by the
user-agent. Today that is not so much of a problem as before -
supporting ol
On Fri, 18 Jul 2003, Weaver, Scott wrote:
> > I know nothing about JMX (Java Management
> > Extensions)(http://java.sun.com/products/JavaManagement/) other than what
> > I
> > just read from the first paragraph of Sun's site. However, I do know a
> > bit
> > about SVG, and IMHO it would be a much
> I know nothing about JMX (Java Management
> Extensions)(http://java.sun.com/products/JavaManagement/) other than what
> I
> just read from the first paragraph of Sun's site. However, I do know a
> bit
> about SVG, and IMHO it would be a much better choice than Flash. Flash =
> proprietary forma
I know nothing about JMX (Java Management
Extensions)(http://java.sun.com/products/JavaManagement/) other than what I
just read from the first paragraph of Sun's site. However, I do know a bit
about SVG, and IMHO it would be a much better choice than Flash. Flash =
proprietary format; SVG = open
Actually, we were discussing the possibility of Flash as a UI in some aspects of J2,
more than likely, admin. Also discussing the use of JMX in J2 admin.
Anyone with JMX experience is more than welcome to comment on this.
*===*
* Scott T Weaver
Weaver, Scott a écrit :
>> I think PortletAction should become a real class, and not a subclass
>> anymore, and contains a render() method that would give it renders
>> (javascript, or whatever). A portlet action would be linked to a
>> control action.
>
> IMOHO, PortletAction should go away enti
> -Original Message-
> From: Jan Grant [mailto:[EMAIL PROTECTED]
>
> (I personally think/hope the pre-generation of images argument will
> hopefully become less of a kicker as browser support for SVG
> increases.)
Amen. SVG fosters all sorts of cool client side UI and DOM manipulation
s
> I think PortletAction should become a real class, and not a subclass
> anymore, and contains a render() method that would give it renders
> (javascript, or whatever). A portlet action would be linked to a control
> action.
IMOHO, PortletAction should go away entirely and the Portlets themselves
Of course there may be a better way to do it, that's just a way I saw
looking at portletaction...
Aurelien Pernoud a ecrit :
> I first thought that was easy, but in fact the hardcoded part of
> portletactions makes it harder than it seems, and I don't know if
> I've thought of everything...
>
>
Gerry Reno a ecrit :
> Scott,
> My apologies for coming at this a little strongly. I didn't intend
> to offend anyone. My comments about the usability of the
> IFramePortlet were actually intended to show that the IFramePortlet
> can be made perfectly usable if we change the view interaction
Sandeep,
I don't understand your argument. This isn't about client-side apps.
Gerry Reno
--- Sandeep Dixit <[EMAIL PROTECTED]> wrote:
> With client apps, you are trading-off ease of maintenance for better
> performance. Imagine maitaining your client application on 100,000
> machines or even f
Well, it would be great if either case could be implemented but right
now there is no choice. And when you think about the two different
models and how the portlets would be developed under each one they are
fairly different although it might be possible to say in the request,
"I am a client-sid
What Jetspeed version are you using? Did you upgrade from an earlier version? Is
your TURBINE_USER USER_ID column set to auto increment? In b3 or 4 it changed from
being generated by idBroker to being autoincrement.
>>> [EMAIL PROTECTED] 07/17/03 11:55PM >>>
Could some one please refer me t
With client apps, you are trading-off ease of maintenance for better performance.
Imagine maitaining your client application on 100,000 machines or even for that matter
100 machines.
Sandeep
--
From: Gerry Reno
Sent: Friday, July 18, 2003 11:19 AM
To: Jetspeed Users List
Subjec
Joachim,
What on earth does accessibility guidelines have to do with types of
scripting technology - this makes absolutely no sense. I can see
restricting certain types of UI behaviors but not implementation
technologies. Where may I find these german requirements.
Gerry Reno
--- Joachim_Mull
> I think that generic statements about this situation are unlikely to
> lead to agreement: one can envisage situations where either case could
> be made.
+1
> Prolog in JavaScript: http://ioctl.org/logic/prolog-latest
[off-topic]
I did some work with FRIL, http://www.enm.bris.ac.uk/research/aig
Scott,
My apologies for coming at this a little strongly. I didn't intend
to offend anyone. My comments about the usability of the IFramePortlet
were actually intended to show that the IFramePortlet can be made
perfectly usable if we change the view interaction model that's all.
Gerry
--- "We
Gerry
we are currently working on a jetspeed project that has to
fulfill the accessibility guidelines as required by the
german goverment for all govermental website from 2005 on.
One statement is to not be dependend on javascript for the
functionality of the website.
If jetspeed pages would re
On Fri, 18 Jul 2003, Weaver, Scott wrote:
> > The issue is where is it most efficient to perform certain
> > functionality. I don't have any problem with concept of displaying a
> > graph next to the tabular data when the portlet is maximized. The
> > problem I have is that this all should be
The way I look at this for something like your graph example is that
it is just as easy to generate this graph in the first request. Once
in the browser the user then can then normalize, maximize the portlet
as many times as they want without requiring any additional trips to
the server. It is
> The issue is where is it most efficient to perform certain
> functionality. I don't have any problem with concept of displaying a
> graph next to the tabular data when the portlet is maximized. The
> problem I have is that this all should be done on the client. When the
> portlet is maximize
I have to admit, Gerry, your initial approach came off quite, um, combative. Telling
us that things in the portal are virtually useless is NOT the way to become a
constructive member of an open source community. I have fairly thick skin as do most
of the developers here (it's a requirement to
Aurilien,
I'm sorry that my comments upset you. I fully realize that there has
been much work put into Jetspeed already and my comments were certainly
not meant to denegrate anybodys work. I am just not comfortable that
the spec lays out a good model and I think consideration should be
given to
Scott,
The issue is where is it most efficient to perform certain
functionality. I don't have any problem with concept of displaying a
graph next to the tabular data when the portlet is maximized. The
problem I have is that this all should be done on the client. When the
portlet is maximized t
> I don't think the Jetspeed list is the right avenue for official
> feedback, however, so I'll shut up now.
Don't be silly. The comments posted here DO carry weight. They get back to us (the
developers) who can send these concerns up the pole so to speak.
*
Gerry Reno a ecrit :
> The spec is dictating a server-side UI
This is, I think, the exact kind of mail that will make jetspeed dev not
read any one single more mail from you. At least that's what I would do.
I'm sorry, but devs and specs have taken time, you just come by there and
say "Hey gu
On Fri, 18 Jul 2003, Gerry Reno wrote:
> Jan,
> The spec is dictating a server-side UI therefore my JSR-168 comments
> completely apply to any container implementing this spec.
I don't read it that way; it deals with a lifecycle when browser events
are delivered to the portlet container - but d
Sandeep,
Well sure and you can use CGI or a lot of other data retrieval
technologies. The point is where is it most efficient to do certain
functionality. Having to make a request to the server just because I
want to minimize a little portlet box in the browser results in a whole
new page being
Jan,
The spec is dictating a server-side UI therefore my JSR-168 comments
completely apply to any container implementing this spec.
Gerry Reno
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
--
I think your proposal holds merit, however, it becomes too restrictive in requiring
that all portlets MUST use client DOM/DHTML to facilitate modifications to the
portlet's window state. Like I said before, some portlets actually do things when
maximized (and yes my users think it's very kewl t
>The issue is that with servlet/JSP you can design your webpages to
>behave in a normal manner and only go to the server when you decide.
I can understand that you use servlet to fetch the XML data and then process it in
your client application. But then you don't need servlet technology at all,
On Fri, 18 Jul 2003, Sandeep Dixit wrote:
> > where every view action, even simple view actions
> > like minimizing a portlet will go back to the server for a full page
> > reload.
>
> I believe that's the case with Jetspeed in its current form as well.
> Rather it is at the very core of the Servl
Sandeep,
The issue is that with servlet/JSP you can design your webpages to
behave in a normal manner and only go to the server when you decide.
You can use client-side DOM techniques to build a very responsive
interface. With the portlet spec you are being forced into a
server-side UI model wi
> where every view action, even simple view actions
> like minimizing a portlet will go back to the server for a full page
> reload.
I believe that's the case with Jetspeed in its current form as well. Rather it is at
the very core of the Servlet/JSP revolution. The model is clearly take a requ
Hello,
>
> Here are some examples of links to panes in Velocity:
>
> $jslink.getPaneById("P_12345")
> $jslink.getPaneById("Pane_3,SubPane_17")
> $jslink.getPaneByName("pane_1")
>
I tried this, but it does seem to work. I am not really sure if what I
want to link to is a subpane. I have a MenuCo
39 matches
Mail list logo
