Re: [xmlc] URL Re-writing and urlregexpmapping

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 xmlc@xxxxxxxxxxxxx
>> mailing
>> >list.
>> >To unsubscribe: mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
>> >For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
>> >ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>>
>>
>>------------------------------------------------------------------------
>>
>>
>>--
>>You receive this message as a subscriber of the xmlc@xxxxxxxxxxxxx mailing
>list.
>>To unsubscribe: mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
>>For general help: mailto:sympa@xxxxxxxxxxxxx?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 xmlc@xxxxxxxxxxxxx mailing
>list.
>To unsubscribe: mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
>For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
>ObjectWeb mailing lists service home page: http://www.objectweb.org/wws



--
You receive this message as a subscriber of the xmlc@xxxxxxxxxxxxx mailing list.
To unsubscribe: mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws