As long as this doesn't require explicit action by the script developer, I could see this working. But that's not how, IIUC, HTL works. Rewriting has to work even if the script developer didn't anticipate that a particular element/attribute/text content needs rewriting.
On Wed, Oct 24, 2018 at 9:21 AM Konrad Windszus <konra...@gmx.de> wrote: > 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 > >> > >
