Project鏈涓昏鏄瑙ｅ喅涓変釜鏂歸潰鐨勯棶棰?
1.鐢ㄤ粈涔圫oftware鏉ョ敓鎴愬彲浜や簰鐨凢orm?
2.鐢ㄤ粈涔圤pen source tools鏉re-fill Form?
3.鍦║ser濉畬Data鍚?鍙堜互浠涔堟柟寮廠ubmit 鍒癝erver澶勭悊?
瀵逛簬絎竴涓棶棰?鑷劧鏄敤Adobe 鐨凷oftware鍟?浣嗘槸鐢ˋcrobat Pro榪樻槸鐢↙ifecycle Designer, 鍗磋鎴戣垂浜嗕笉灝戝姴.涓轟粈涔堝挧?鍥犱負Acrobat Pro鍜孡ifecycle Designer 澶勭悊鐨凢orm鐨勬牸寮忔槸涓嶄竴鏍風殑. Acrobat Pro閲岄潰鐢ㄧ殑鏄疉croForm,鏄疉crobat3.0寮濮嬬敤鐨勬牸寮?鑰孡ifecycle Designer閲岄潰鐢ㄧ殑鏄疿fa Form,鏄熀浜嶺ML鐨? 涓よ呯殑涓嶅悓璇峰弬鑰冧互涓嬬殑鎽樺綍:
The interactive forms that you create in LiveCycle Designer are different than the interactive forms that you create in Adobe Acrobat. If you create an interactive form in Acrobat, your form is based on Adobe’s Acroform technology. This technology dates back to Acrobat version 3, and Adobe provides the “Acrobat Forms API Reference” to provide the technical details for this technology. I would not recommend using Acroform technology because XFA is the better technology.
If you are moving from Acroforms to XFA forms, you need to know a couple of important facts about these two technologies:
1.LiveCycle Designer can edit a PDF form created in Acrobat, but Acrobat cannot edit a PDF form created in Designer.
2.JavaScript works differently in these two technologies. Some of the JavaScript routines that work in Acroforms will not work in XFA forms. Adobe has documented these differences in a 43 page online PDF called, “Converting Acrobat JavaScript for Use in LiveCycle Designer Forms.” Designer is a much more robust tool for using JavaScript in your forms, so I recommend that you learn how to script with the XFA object model. See Chapter 4, “Form Scripting,” for more information.
PS: you can find more in the below link: More info about XFA
Lifecycle designer 鏄悗鏉ユ墠鏈夌殑涓滆タ,鑷劧鏄瘮Acrobat Pro鏇村厛榪涗篃鏇撮傚悎鐢ㄤ簬浜や簰,浣嗘垜鐨勯」鐩渶緇堣繕鏄変簡Acrobat Pro,鍥犱負鎴戠殑絎簩涓棶棰樼殑絳旀鏄痠Text. iText鍙互鐢ㄦ潵Pre-fill XFA鏍煎紡鐨凢orm,浣嗘槸涓嶇煡閬撲負浠涔堢敤iText Create鐨剆ubmit button涓嶈兘submit XFA form(鎸変簡Button鍚庢病鏈夊弽搴?,鍚庢潵涓婄綉鏌ュ埌鍘熸潵iText涓嶆敮鎸乆FA Form, 鎵浠ヤ篃鍙兘鐢ˋcrobat鍟?
鑰屼笖鐢ˋcrobat Pro鍒涘緩鐨凢orm鏈変袱涓垜鑷繁瑙夊緱涓嶉敊鐨勪紭鐐?浠extFeild綾誨瀷涓轟緥瀛?:
1. Acrobat Pro鍒涘緩鐨凙croForm鏄病鏈夊眰嬈＄粨鏋勭殑,鑰孡ifeCycle Desinger鍒涘緩鐨凢orm鏄湁灞傛鐨?浠涔堟剰鎬濆挧?涓句釜渚嬪瓙,鍚屾牱鏄疉dd涓涓猅extFeild, 鎶婂畠鍛藉悕涓篊ustomerName,鍦ˋcroForm閲岄潰鐨勫悕瀛楀氨鏄疌ustomerName鍟?鑰屽湪XFA Form閲岄潰灝辨垚浜唗opmostSubForm[0].Page1[0].CustomerName[0],鍜嬩竴鐪?榪樼湡鏄儲.鑰屼笖浣犵殑PDF涓鏀圭殑璇?閭ｄ綘鐨凢eild name涔熺浉搴旀敼浜?榪欐牱Program涔熻鏀逛簡....
2. Acrobat Pro鍒涘緩鐨凙croForm鐨凾extFeild鍙互鑷傚簲澶у皬,涓涓猅extFeild鎬繪槸鏈変竴瀹氱殑闀垮害,浣嗚濉殑Value灝變笉鐭ユ湁澶氶暱鍟?鏈夊彲鑳芥湁涓狢ustomerName鐪熺殑寰堥暱鍜?榪欏湪XFA Form閲岄潰灝變細鏈変簺Value Show涓嶅嚭鏉?浣咥crobat Pro鍒涘緩鐨凙croForm鐨凾extFeild灝卞彲浠ユ牴鎹甐alue鐨勫ぇ灝忚屾敼鍙樺瓧浣撶殑澶у皬鏉ラ傚簲TextFeild鐨勯暱搴?
浠ヤ笂涓ょ偣鏄垜鑷繁鐨勮璇?涔熻Lifecycle Designer涔熷彲浠ュ仛鍒頒互涓婄殑鏁堟灉,浣嗙洰鍓嶆垜鏄笉浼?鍥犱負鎺ヨЕLifecycle Designer姣旇緝灝?濡傛灉鏈夊ぇ铏劇煡閬撶殑璇濊澶氬鎸囨暀.
]]>
The problem is that there is a limit on the size of a compiled method in a
Java class file, and that limit is what we're running up against. Recall
that a JSP page is compiled into a servlet, and into essentially only one
method in that servlet. Hence, if your page contains many, many tags, that
method becomes too big, and up comes the exception that you're seeing.
There are a couple of (partial) solutions.
1) Break your giant page up into multiple smaller pages and bring them
together at run time using <jsp:include>. Note that <%@include> won't work,
because that's a compile-time include, which will get you straight back to
the original problem.
2) Look for places to save on tags. For example, the <html:option> tag was
recently extended to allow the specification of the text to display, so
that you can replace this:
<html:option ... ><bean:message key="foo"/></html:option>
with this:
<html:option ... key="foo"/>
More info pls access this link: Solution
鎴戝氨鏄敤浜嗙涓縐嶆柟娉曡В鍐崇殑,涔嬪墠include JSP鐨勬椂鍊欑敤浜?a href="mailto:%@include">%@include, 鍚庢潵鐢ㄤ簡<jsp:include>灝變笉浼氱敤闂浜?欏轟究璐翠竴涓嬩袱鑰呯殑鍖哄埆:
鍚庤:緗戜笂榪樻湁涓縐峉olution:
try giving this in the deployment descriptor.
<jsp-param>
<param-name>noTryBlocks</param-name>
<param-value>true</param-value>
</jsp-param>
鏈漢娌℃湁璇曡繃, 涓嶇煡濂戒笉濂界敤....
]]>