[EMAIL PROTECTED] wrote:
>
>
> Santiago Gala wrote:
>
>
>> Do you mean that javax.servlet.* is more standard than javax.xml.* (Trax
>
> and Jaxp)?
>
> What I am trying to point out is that it is not good for a standard Java
> API depend on other Java APIs that are not part of the JDK classes.
> If you look at javax.servlet for example, it has no dependencies on any
> other Java extension, only on classes and interfaces in the JDK classes.
> Whenever possible, dependencies of Java APIs to classes/interfaces that are
> not JDK classes should be avoided.
>
Yes. I would also like to minimize dependencies. But I look also for a way to
integrate other
frameworks. This is where the clash comes, I think.
>
>> Maybe it is true, but I can't see it.
>> The servlet API contains a specific method of creating output, namely
>> writing to a response stream.
>
>
> Writing to the response stream just seems like the natural way of
> outputting content to me - and probably to many people used to write
> servlets. I think this is different than using SAX, DOM, or ECS.
>
For servlet, and CGI, programmers, this is true. But, for instance, jsp, ASP,
coldfusion, php, ... programmers
will think in terms of filling a template. They don't understand the issues of the
response stream. For static HTML
designers, it will look like "putting a document somewhere".
For XML people, it again looks similar to those templating environment. They think in
terms of a document
that is transformed and "magically" sent to the client.
Under the hood, we should try to do clever things to avoid object allocation and
garbage. But, to the
user, our API should be friendlier than "just servlet".
My view here is that having a event stream instead of a byte stream allows for nice
shortcuts in the
implementation in the case where you are handling well-formed XML languages (fragments
or elsewhere).
In the case of XSLT transformations, it avoids paying high tolls for reparsing.
The problem here is that we are aggregating content. So, there are recursive
concepts going on (a window composed of windows,...). I'll try to explain:
Some definitions (informal):
- content is layout, media and l&f independent.
- layout is putting together several content sources (content+positioning information).
- styling is rendering in a media/l&f/user-agent dependent way positioned content.
The processes I try to describe here are similar to the publishing industry processes:
first you have a content item, written by an author, then you select content items and
put them in pages. Styling is more complex, since there is "inline style",
like font,emphasis info, and "block style", like column width and decorations.
There seem to be two views on content aggregation as a whole in the list:
- we can first aggregate content, and then the container will lay it out and style it.
(This is my view)
- we can style content, then have laid out and aggregated by the container. (This seem
to be your view)
The first view can be implemented by having the portlet writing to a "content event
stream", and
then having the container transform this event stream (on the fly) to the needed media
document.
Using an event approach like SAX will make this process quite efficient, as the whole
process will take place synchronously. There is no post-processing here (except in the
conceptual
view). If I cannot use a event stream to handle output, then I will need to have
postprocessing,
and most of your concerns will apply. This is why I NEED event streams.
I agree that current implementations (specially if they are not
concerned about multidevice rendering) will go the second way.
But I feel that THE WAY is the first way. This idea will gradually open
in the minds of managers as they have to manage 4 content types,
navigator versions, personalisation, etc. Also, there is different
people doing content production and styling. We should separate the
content and style processes as much as possible.
My concerns is that the portlet API should have a way to allow for
aggregation of content before styling as I feel it will be the way
to go in a short amount of time.
I think I am getting constructive here. :)
BTW, Sorry if some of my posts were stressing. I think my feelings
betray me sometimes.
Please feel free to correct me and continue the discussion, without
thinking in "urgent" votes, or winning or losing, just for the sake of
building common understanding :)
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
