Re: [xmlc] URL Re-writing and urlregexpmapping
James Rochford <[email protected]> Thu, 21 Jul 2005 09:26:49 -0600
| Newsgroups | gmane.comp.java.enhydra.xmlc |
|---|---|
| Message-ID | <[email protected]> |
I did as you asked. I built the latest snapshot and it looks as if
setURLRewriteAttributes is working as advertised. URL Rewriting is
working great and I no longer have any problems compiling my web pages.
So from where I'm sitting things look good. Thanks for all the work.
James
James Rochford wrote:
>
> It seems at the time of my email the method setURLRewriteAttributes
> was just being talked about. I had checked out the latest from cvs in
> hopes that it was there but it wasn't . So my solution was a quick
> hack. I'm more then happy to grab the latest again and see if the
> issue is resolved. I will let you konw what I find. Thanks.
>
> James
>
>
>
> Jacob Kjome wrote:
>
>> I'm just now getting around to look at this and I'm not quite sure
>> there's an issue? From your description, it seems that you are
>> actually modifying the HTMLDomFactoryMethods.java source and changing
>> the private static String[] URL_ATTRIBUTES to be what I must have
>> suggested in a previous email. If so, you don't need to do that.
>>
>> Here's the thing. I made the change to OutputOptions to allow for
>> configuring the attributes you specifically want to be url rewritten
>> at runtime. This should not affect XMLC compilation of pages at
>> all. Before I made this configurable, I may have suggested a
>> physical change to the URL_ATTRIBUTES variable as a quick and dirty
>> work around to what you were seeing. However, the new way to do this
>> is (example below for XHTML output)...
>>
>> org.enhydra.xml.io.OutputOptions oo =
>> context.createOutputOptions(req, res, xmlObj);
>> oo.setEnableXHTMLCompatibility(true);
>> oo.setUseAposEntity(false);
>> oo.setURLRewriteAttributes(new String[]{"href"}); //look at
>> this line!!!!!!
>> context.writeDOM(req, resp, oo, xmlObj);
>>
>>
>> So, I'm thinking you are running into this issue only because you are
>> needlessly modifying the XMLC source code. Can you build from the
>> HEAD and try this out? You should have no problems at XMLC compile
>> time. The sooner you test, the better. Because once I verify that
>> this is not an issue, then I can do a 2.2.7 release (after
>> contemplating a couple other unrelated issues).
>>
>> ..... or is this a deferred parsing/dynamic loading issue? In any
>> case, please verify whether or not this is a real issue.
>>
>>
>> Jake
>>
>>
>> At 09:21 AM 6/6/2005 -0600, you wrote:
>> >Jacob,
>> >
>> >Thanks for the quick reply. I was able to find an ugly hack that
>> solved
>> >my problem so I'm good to go for now. If anyone else is having the
>> same
>> >problem I'll be happy to post my solution.
>> >
>> >Best regards,
>> >
>> >James
>> >
>> >Jacob Kjome wrote:
>> >
>> >>
>> >> Hmm... I didn't realize this when I made the change. We really need
>> >> to get the tests working properly under the current build framework.
>> >> Many fail, but I think they are failing in some cases because test
>> >> files are expected to be relative to the location that the VM started
>> >> and that isn't happening properly with the sub-builds. This would
>> >> have been caught. I haven't looked at the issue closely enough to
>> >> really understand what the problem is.
>> >>
>> >> In any case, this is certainly a bug and we can't release a new
>> >> version with this issue. I will try to look at it this weekend,
>> but I
>> >> can't promise. My time is limited. Anyone else care to take a crack
>> >> at it? While you are at it, there's always the improper adding of
>> >> line breaks to XHTML output which affects both normal output and
>> >> pretty printing. I haven't been able to track down the cause as of
>> >> yet. Hoping for some help!
>> >>
>> >>
>> >> Jake
>> >>
>> >> At 10:11 AM 6/3/2005 -0600, you wrote:
>> >> >Hello,
>> >> >
>> >> >It seems that both urlrewriting and urlregexpmapping both rely on
>> >> >URL_ATTRIBUTES. In order to make urlrewriting behave the way I
>> needed I
>> >> >removed all references to event attributes as per Jacobs
>> suggestion. Now
>> >> >it looks like this.
>> >> >
>> >> >private static String[] URL_ATTRIBUTES = {
>> >> > "action", "archive", "background", "cite", "classid",
>> >> "codebase",
>> >> > "data", "href", "longdesc", "profile",
>> >> > "src", "usemap"
>> >> > };
>> >> >
>> >> >
>> >> >
>> >> >But that created another problem with urlregexpmapping. If I
>> have an
>> >> >html element like
>> >> >
>> >> > <select name="selectElement"
>> >> >onClick="submitForm(this.form,'somePage.html')>
>> >> >
>> >> >and I want to have a urlregexpmapping in my options.xmlc file
>> like the
>> >> >following it no longer works.
>> >> >
>> >> >-urlregexpmapping "somePage\\.html\\"
>> >> >"someOtherPage.jawf"
>> >> >
>> >> >So for now I have to compile my html pages with a non-modified
>> version
>> >> >of xmlc and use my modified version for runtime. I'm going to
>> see if I
>> >> >can hack a solution for my needs but I'm open to any suggestions.
>> >> >
>> >> >Best regards,
>> >> >
>> >> >James.
>> >> >
>> >> >
>> >> >
>> >> >--
>> >> >------------------------
>> >> >James Rochford
>> >> >Software Engineer
>> >> >Samba Holdings, Inc.
>> >> >(505) 797-2622 ext. 129
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >--
>> >> >You receive this message as a subscriber of the [email protected]
>> >> mailing
>> >> >list.
>> >> >To unsubscribe: mailto:[email protected]
>> >> >For general help: mailto:[email protected]?subject=help
>> >> >ObjectWeb mailing lists service home page:
>> http://www.objectweb.org/wws
>> >>
>> >>
>> >>------------------------------------------------------------------------
>>
>> >>
>> >>
>> >>--
>> >>You receive this message as a subscriber of the [email protected]
>> mailing
>> >list.
>> >>To unsubscribe: mailto:[email protected]
>> >>For general help: mailto:[email protected]?subject=help
>> >>ObjectWeb mailing lists service home page:
>> http://www.objectweb.org/wws
>> >>
>> >>
>> >
>> >--
>> >------------------------
>> >James Rochford
>> >Software Engineer
>> >Samba Holdings, Inc.
>> >(505) 797-2622 ext. 129
>> >
>> >
>> >
>> >
>> >--
>> >You receive this message as a subscriber of the [email protected]
>> mailing
>> >list.
>> >To unsubscribe: mailto:[email protected]
>> >For general help: mailto:[email protected]?subject=help
>> >ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>>
>
>------------------------------------------------------------------------
>
>
>--
>You receive this message as a subscriber of the [email protected] mailing list.
>To unsubscribe: mailto:[email protected]
>For general help: mailto:[email protected]?subject=help
>ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
--
------------------------
James Rochford
Software Developer
Samba Holdings, Inc.
(505) 797-2622 ext. 129
message-footer.txt
(text/plain, 269 B)
-- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws