IMHO modifying the script would not even be necessary in the best case for HTL as the HTL context would lead to automatically invoking a certain HTL plugin which allows to modify the link itself. So I totally agree we need aspect-oriented programming here (i.e. only do it once in code instead of hundreds of times explicitly in HTL).
Konrad > On 24. Oct 2018, at 15:16, Justin Edelson <jus...@justinedelson.com> wrote: > > As I was trying to say, this assumes that modifying the script (or the > model or even the content) is an option. In many cases it isn't. How often, > I don't know, but I'm sure it is more than 5% (although I guess it depends > on how this is measured). > > > > On Wed, Oct 24, 2018 at 1:20 AM Carsten Ziegeler <cziege...@apache.org> > wrote: > >> 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 >>
