David et al:
I was able to get my PDF gen working again by starting with new components. I
used the wocomponent wizard, allowed it to create the html and left the doctype
as xhtml transitional. Essentially building from there with a document saying
Hello World, I was able to get things working again.
I haven’t solved why components that worked before didn’t work anymore.
Tim
UCLA GSE&IS
On May 9, 2014, at 2:52 PM, Timothy Worman <li...@thetimmy.com> wrote:
> Hi David:
>
> I guess I’m not alone in the wilderness! At least this means it isn’t my
> fault - this time!! I haven’t had time to look into it at all today. Maybe
> the supporting libraries were updated and something got broken. When I have a
> chance I’ll start looking at when the ERPDFGeneration framework may have had
> updates.
>
> Tim
> UCLA GSE&IS
>
> On May 8, 2014, at 1:11 PM, David Holt <programming...@mac.com> wrote:
>
>> I am seeing the same issue that you are with ERPDFGeneration. Disabling
>> click to open has no impact on the problem.
>>
>> David
>>
>>
>> On 2014-05-08, at 12:29 PM, Timothy Worman <li...@thetimmy.com> wrote:
>>
>>> I was suspecting the _componentName attribute yesterday and I was looking
>>> for properties to turn it off. After a quick search I didn’t find anything.
>>> It does appear that clickToOpen could be involved and I have the property
>>> set true in my props. I haven’t used it so I don’t know why I have it
>>> enabled. And I seem to remember reading it caused issues with excel
>>> generation. This could be it. I’ll respond with more after some
>>> investigation.
>>>
>>> Tim
>>> UCLA GSE&IS
>>>
>>> On May 8, 2014, at 9:41 AM, Fabian Peters <lists.fab...@e-lumo.com> wrote:
>>>
>>>> I somehow assumed this problem occurred in deployment. Still, if Bastian
>>>> is on the right track, then this should help:
>>>>
>>>> public boolean clickToOpenEnabled(WOResponse response, WOContext
>>>> context) {
>>>> return false;
>>>> }
>>>>
>>>>
>>>> Am 08.05.2014 um 18:15 schrieb Bastian Triller <bastian.tril...@gmail.com>:
>>>>
>>>>> I think the _componentName attribute is the problem. There's a switch to
>>>>> turn that off.
>>>>>
>>>>> On Wed, 2014-05-07 at 19:33 -0700, Timothy Worman wrote:
>>>>>> All:
>>>>>>
>>>>>>
>>>>>> I have a problem that recently popped up with PDF generation. I have a
>>>>>> custom component that utilizes the simple FlyingSaucerImpl in
>>>>>> ERPDFGeneration. My component was failing with:
>>>>>>
>>>>>>
>>>>>> "[org.xml.sax.SAXParseException] The markup in the document preceding
>>>>>> the root element must be well-formed."
>>>>>>
>>>>>>
>>>>>> So, I simplified things and basically made a test component content sth
>>>>>> like SimplePDFGeneration1 from the ERPDFExamples. Same issue -
>>>>>> SAXParseException. I overrode appendToResponse to generate some
>>>>>> diagnostics on the content I’m trying pdf-ify (is that allowed?). Below
>>>>>> is what it sayeth. So, what the heck is in line 0, column 2 in the
>>>>>> document?
>>>>>>
>>>>>>
>>>>>> May 07 19:20:21 eTimesheet[55555] WARN NSLog -
>>>>>> 'edu.ucla.gseis.employee.components.TimesheetCalendarPDFComponent'
>>>>>> caused a SAXParseException
>>>>>> Message: 'The markup in the document preceding the root element must be
>>>>>> well-formed.'
>>>>>> Line : 0
>>>>>> Column : 2
>>>>>> --- content begin ---
>>>>>> 1 <!DOCTYPE html>
>>>>>> 2 <html _componentName =
>>>>>> "edu.ucla.gseis.employee.components.TimesheetCalendarPDFComponent" lang
>>>>>> = "en">
>>>>>> 3 <head>
>>>>>> 4 <meta charset = "utf-8" />
>>>>>> 5 <title>ERPDFGeneration Examples</title>
>>>>>> 6
>>>>>> 7 <link rel="stylesheet" type="text/css"
>>>>>> href="/cgi-bin/WebObjects/eTimesheet.woa/_wr_/wodata=/Users/worman/Source/etswo/eTimesheet/WebServerResources/print.css"
>>>>>> media="print"/>
>>>>>> 8
>>>>>> 9 </head>
>>>>>> 10 <body>
>>>>>> 11
>>>>>> 12 </body>
>>>>>> 13 </html>
>>>>>> --- content end —
>>>>>>
>>>>>>
>>>>>> Tim
>>>>>> UCLA GSE&IS
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>> Webobjects-dev mailing list (
>>>>>> Webobjects-dev@lists.apple.com
>>>>>> )
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>
>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/bastian.triller%40gmail.com
>>>>>>
>>>>>>
>>>>>> This email sent to
>>>>>> bastian.tril...@gmail.com
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>> https://lists.apple.com/mailman/options/webobjects-dev/lists.fabian%40e-lumo.com
>>>>>
>>>>> This email sent to lists.fab...@e-lumo.com
>>>>
>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/webobjects-dev/programmingosx%40mac.com
>>>
>>> This email sent to programming...@mac.com
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/lists%40thetimmy.com
>
> This email sent to li...@thetimmy.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
