Details
-
Type: Improvement
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 1.6
-
Component/s: Tool Integrations
-
Labels:None
-
Environment:netbeans vwp
Description
The main argument is that I would really like to divide problems into a limited scope and finish it within target code base.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
java.lang.ClassCastException: org.apache.xerces.parsers.XML11Configuration
at org.apache.xerces.parsers.DOMParser.<init>(Unknown Source)
at org.apache.xerces.parsers.DOMParser.<init>(Unknown Source)
at com.sun.rave.designer.markup.RaveDomParser.<init>(RaveDomParser.java:26)
at com.sun.rave.designer.markup.RaveDocumentBuilder.<init>(RaveDocumentBuilder.java:114)
at com.sun.rave.designer.markup.RaveDocumentBuilderFactory.createDocumentBuilder(RaveDocumentBuilderFactory.java:97)
at com.sun.rave.designer.markup.RaveDocumentBuilderFactory.newDocumentBuilder(RaveDocumentBuilderFactory.java:89)
at com.sun.rave.designer.markup.MarkupServiceImpl.createRaveSourceDocumentBuilder(MarkupServiceImpl.java:285)
at com.sun.rave.api.designer.markup.MarkupService.createRaveSourceDocumentBuilder(MarkupService.java:202)
at com.sun.rave.insync.markup.MarkupUnit.parseDom(MarkupUnit.java:300)
at com.sun.rave.insync.markup.MarkupUnit.read(MarkupUnit.java:455)
at com.sun.rave.insync.SourceUnit.sync(SourceUnit.java:480)
at com.sun.rave.insync.faces.FacesPageUnit.syncSubUnits(FacesPageUnit.java:222)
at com.sun.rave.insync.beans.BeansUnit.sync(BeansUnit.java:186)
at com.sun.rave.insync.live.LiveUnit.sync(LiveUnit.java:297)
at com.sun.rave.insync.live.LiveUnitWrapper.sync(LiveUnitWrapper.java:120)
at com.sun.rave.insync.models.FacesModel.syncImpl(FacesModel.java:1008)
at com.sun.rave.insync.Model.sync(Model.java:194)
at com.sun.rave.insync.models.FacesModelSet.findDesignContext(FacesModelSet.java:622)
at com.sun.rave.insync.models.FacesModelSet.findDesignContext(FacesModelSet.java:592)
at com.sun.rave.jsfsupport.designtime.LoadBundleVariableResolver.resolveVariable(LoadBundleVariableResolver.java:80)
at com.sun.faces.el.VariableResolverChainWrapper.getValue(VariableResolverChainWrapper.java:93)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:143)
at com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:62)
at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:65)
at com.sun.el.parser.AstValue.getValue(AstValue.java:106)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:192)
at com.sun.faces.application.ValueBindingValueExpressionAdapter.getValue(ValueBindingValueExpressionAdapter.java:102)
at com.icesoft.faces.component.custom.renderkit.dt.renderer.TreeRenderer.encodeBegin(TreeRenderer.java:142)
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:810)
at com.sun.rave.insync.faces.FacesPageUnit.renderBean(FacesPageUnit.java:1251)
at com.sun.rave.insync.faces.FacesPageUnit.renderNode(FacesPageUnit.java:1485)
at com.sun.rave.insync.faces.FacesPageUnit.renderBean(FacesPageUnit.java:1299)
at com.sun.rave.insync.faces.FacesPageUnit.renderNode(FacesPageUnit.java:1485)
at com.sun.rave.insync.faces.FacesPageUnit.renderBean(FacesPageUnit.java:1299)
at com.sun.rave.insync.faces.FacesPageUnit.renderNode(FacesPageUnit.java:1485)
at com.sun.rave.insync.faces.FacesPageUnit.renderBean(FacesPageUnit.java:1299)
at com.sun.rave.insync.faces.FacesPageUnit.renderNode(FacesPageUnit.java:1485)
at com.sun.rave.insync.faces.FacesPageUnit.renderBean(FacesPageUnit.java:1299)
at com.sun.rave.insync.faces.FacesPageUnit.getFacesRenderTree(FacesPageUnit.java:1069)
at com.sun.rave.insync.faces.FacesPageUnit.renderHtml(FacesPageUnit.java:1607)
at com.sun.rave.insync.models.FacesModel.getHtmlDomFragment(FacesModel.java:1554)
at com.sun.rave.insync.models.FacesModel.findHtmlBody(FacesModel.java:1578)
at com.sun.rave.insync.models.FacesModel.getHtmlBody(FacesModel.java:1566)
at com.sun.rave.insync.InSyncServiceProvider.getHtmlBodyForMarkupFile(InSyncServiceProvider.java:355)
at com.sun.rave.insync.Util.isSpecialBean(Util.java:623)
at com.sun.rave.insync.live.DesignBeanNode.canCopy(DesignBeanNode.java:432)
at org.openide.explorer.ExplorerActionsImpl.updateActions(ExplorerActionsImpl.java:215)
at org.openide.explorer.ExplorerActionsImpl.access$400(ExplorerActionsImpl.java:65)
at org.openide.explorer.ExplorerActionsImpl$ActionStateUpdater.actionPerformed(ExplorerActionsImpl.java:667)
HEAD built is not working with stream writing any more. This means under the environment where libraries' ViewHandler without D2DViewHandler initialized, the HEAD built is not compatible.
For 1.6 release, we use a design time renderer for now.
/icefaces-webui-base is init under tools repository.
Sun's using design time renderer for some of the renderer, not all of them. Mainly just delegate to run time renderer and modify if necessary.
Basically webui jsf 1.2 implementation: https://woodstock.dev.java.net/index.html
Frank
Before we consider implementing a custom renderkit for
design time, we need to verify if there are simple things
we can do with the current components that will make them
work equally well in design time and run time.
The main issue is that DOMResponseContext, casting to
BridgeFacesContext, stepOver(), and streamWrite() should
no longer be necessary – our renderers should work with
the standard ResponseWriter. (This is due to the switch
to the clean DOM). The evidence for this is
the fact that many of the Tomahawk components work when
running under ICEfaces. If this doesn't work, then we
need to revisit the clean DOM implementation and determine
if it's buggy. The basic theme is that we can't require all
of these proprietary APIs in our components because if
they're necessary, we'll never have compatibility with
3rd party components.
So, I would like to ask Frank and Adnan to pick a component
(either custom or very basic) and look at what needs to be
fixed to make it work in design time. Once we've gone through
that exercise, we can (hopefully) apply the strategy uniformly
to all the components.
Thanks,
Ted.
yes or no, it depends:
for example: dataTable will only display the required dataModel (only
metadata from database related to the SQL query). No real data.
so a dummy info is displayed. But the jsp page is the persistent storage
for the user's action. so the jsp page is changed.
properties of components is stored at design bean associated with
component. Visual element needs to change:
for example: popup calendar will change visually comparing with input
calendar.
Some of the properties like actionLister or action is not related
For example:
It is separated code written for Page.java related to Page Bean as well
as jsp page.
thanks,
Frank
It seems like a good idea. I think the question is, Whether the control of
> the component on the palette needs to manifest the property changes in
> design time or not? if yes then it would be hard to have two separate
> renderKits which always renders the same output but for different
> environments. if no then it is better to have separate one.
>
> Thanks,
> Adnan
take serveral steps to convert to use Response Writer from IDE or other implementation...
step by step converting ... (Using the same code base for 1.5 HEAD, remove dependencies and gradually refactoring existing code base)
#1. Separate Library dependencies:
icefaces-comps.jar file with tld (default component library).
not dependent on icefaces.jar to init.
survive with Faces Servlet, other ViewHandler (or delegate ViewHandler)
complete separate between API and Impl
#2. Naming Packaging completely separated (renderer/compponent)
renderer stays in one package
changes renderer class name in faces-config.xml (override or delegate if possible)
#3. core ICEfaces eats DOMException now ...( no tracking of problem)
DOM manipulate
#4. Log difference (IDE JDK logging only)
#5. avoid class casting (Reflection)
#6. no changes in Renderer over time
less code with designt time once refactoring complete... (step by step)
design time, time consuming to debugging. needs more stable code base. (visual element output only)
#7. No way to automated testing, so alternatively to use Faces Servlet and standard API only.
hopefully design time support container could be inited and used to test Renderer
#8. strict environment rules are not necessary for Run time (work around in most occasions)
many work around in run time.
#9. Once existing Renderer refactor to use Response Writer only.
delegate rendering possible at that stage.
icefaces-webui-base is introduced into repository.
Design Time renderer is enabled