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