In addition to that, it seems to me wrong to write a script which
creates an output (being that html or json or whatever) and then you
need an additional mechanism to modify this output. Wouldn't it be much
better to create the correct output in the first place?
So I think there are three places where you potentially do the
modifications:
1. You modify your model which is the input to your script
2. You do it in a script
3. You reparse the output of your script and then modify it
Maybe there are still use cases for 3 and then the rewriter is a good
tool for it. But I sincerely hope that 95% of the use cases can already
be solved with 1 or 2 - and thats were we should focus on.
Carsten
Am 24.10.2018 um 06:55 schrieb Carsten Ziegeler:
As usual we're giving ourselves and our users a hard time as we want to
support all the possible options in the world instead of focusing on one
or two options and make them as good as possible. I don't care what the
solution is, but supporting 5 different ways of creating html is imho
totally wrong and fragmenting our user base. Whether it is HTL or not is
a different question.
The current architecture of the rewriter is not optimal as it needs to
reparse the output which is expensive. The servlet API has no support
for streaming text based outputs so as long as we have that API in
between we have a bad solution. Building on top of something where we
know that its not a good thing, seems wrong to me as well.
Carsten
Am 24.10.2018 um 01:45 schrieb Justin Edelson:
Just my 2cents as a fan of the rewriter.
The problem with saying "just use HTL" (aside from what Jason said) is
that
it enables a separation of concerns. To say "just use HTL" implies that
there is a single developer (or organization) who "owns" all the code
responsible for generating HTML and has the authority to change them to
suit emerging requirements (which today can be done universally via a
rewriter transformer). But this isn't really the case a lot of the
time --
there's multiple "owners" who are each contributing components and
applying
rewriter-style logic across those owners is complicated (if not
impossible)
to manage. This also assumes that HTL (or any other scripting language
generating HTML) is actually being used properly -- in my experience,
there's plenty of "raw" HTML being output from string properties and you
need a way to rewrite that too.
I really don't think all the rewriter use cases boil down to link
rewriting.
https://www.slideshare.net/justinedelson/mastering-the-sling-rewriter/13
is
a real-world example. But I'll need to dig through my project archive to
come up with good examples.
Personally, I'd suggest that HTL could be more tightly coupled to the
rewriter and rather than emit a character stream which gets parsed into a
SAX stream, the rewriter could be reimagined as a more generic event
stream
processing chain and HTL is directly providing HTML events into this
chain
(and given that HTL knows the output context, it could indicate as
part of
the event that the text content should be parsed in the case of embedded
HTML). The output of JSPs could be parsed as is the current state. JSON
could be handled through different event types.
On Tue, Oct 23, 2018 at 4:00 PM Carsten Ziegeler <cziege...@apache.org>
wrote:
The rewriter as it is today is pretty heavy and adds a lot of overhead
to request processing. Especially as the output needs to be created
first and then parsed again.
There is nothing wrong with enhancing it in general. But for example if
you use HTL we could provide much better and faster support ootb. I
think if JSON is rendered we could do something at JSON creation time
instead of needing to reparse it again as well.
I agree that it gets pretty hard to come up with a solution that targets
all output formats at once, even with the rewriter concept it's not that
easy. But maybe we can come up with different implementations that share
a single configuration. For example for link rewriting that should be
possible.
Carsten
Am 23.10.2018 um 21:43 schrieb Daniel Klco:
I don't see how we could support multiple templating languages without
some
sort of rewriter support.
Part of the problem IMO is that the Rewriter library muddles the
rewriting
concept with an expectation of specifically dealing with (X)HTML.
Instead
it would make more sense to me to have a content agnostic library for
performing content rewriting and providing a HTML, XML and (possibly)
JSON
implementation.
On Tue, Oct 23, 2018 at 1:32 PM Jason E Bailey <j...@apache.org> wrote:
On Tue, Oct 23, 2018, at 1:24 PM, Konrad Windszus wrote:
I would rather prefer to get rid of a server side postprocessing
like
the rewriter. For HTL I agree with Carsten, we should probably look
into
a generic link rewriting mechanism which allows for custom rewriting
with a nice HTL plugin. Much less overhead than a Cocoon pipeline
which
needs to deserialize and then serialize again...
Would be interesting to get forward in that regard with Sling 12.
There is a real world need for html post processing that is not
dependent
on HTL. The rewriter is already not a core component and something
that
is
community supported so I don't think enhancing it should be much of an
issue. For what it's worth though I don't like the overhead of the
existing
pipeline as it is anyway. HTML doesn't have anything to do with XML
anymore.
For JSON and client side rendering the link rewriting must be rather
encapsulated on the client side as well. I don’t think Sling should
provide that functionality as Sling is focusing on the server side.
Missing a point here I think. If you are focusing on link rewriting,
that
is something that can only occur on the server side. Helps with
multi-tenancy and cross linking.
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
