kennas / dojoserverfaces Goto Github PK

Since the dataGrid connected DataStore is ItemFileReadStore. it does not allow to be edit. So remove this attribute in the showcase sample.

Add the following manifest entries to output JARs so we can identify the JARs as belonging to DSF/Dojo:

Created-By: Dojo Foundation
Specification-Title: DojoServerFaces
Specification-Vendo r: dojotoolkit Foundation
Specification-Version: 1.7

As dojo.require is going to be deprecated in starting with dojo 1.7, we need to change related codes to use the new AMD scheme. like:

require([
"dijit/form/textbox",
"dijit/form/button",
"dijit/dialog
…
”],
function(){
// All required modules now have been loaded
}
});

I found that scripts emitted by EventPropertyHandler is not consistent with JSF and caused some problems. In the case below, when clicked on the button, you'll get an alert dialog, and the page will be refreshed. But if replace the dojo:button with h:commandButton, it works well.

<h:form>
<dojo:button label="Login" type="submit">
    <f:ajax execute="@form" />
</dojo:button>
</h:form>

Rendered scripts:

1. dojo:button - jsf.ajax.request(...)
2. h:commandButton - jsf.util.chain("elem", event, jsf.ajax.request(...)); return false;

Another difference is: if no f:ajax attached, h:commandButton will emits "return jsf.util.chain(...)" while dojo:button won't return anything.

In the following case, the listener "login.test(AjaxBehaviorEvent)" will not be invoked.

<h:form id="form">
    <h:outputLabel for="username" value="Username:" />
    <h:inputText id="username" value="#{login_backing.username}" />
    <h:outputLabel for="password" value="password:" />
    <h:inputText id="password" value="#{login_backing.password}" />

    <dojo:button id="login" value="Login">
        <f:ajax execute="username" render="result" listener="#{login_backing.test}" />
    </dojo:button>
</h:form>


@ManagedBean(name = "login_backing")
public class Login {
    private String username;
    private String password;

    public void test(AjaxBehaviorEvent evt) {
        System.out.println(((AjaxBehavior) evt.getBehavior()).getExecute());
        System.out.println("username=" + username + ", password="
                + password);
    }
}

This behavior is mainly (but not limited) used with ToggleButton, like:
<dsf:toggleButton label="Click Me" checked="true">
<dsf:toggleProperty target="@this" name="label" initialValue="Toggle me off" compareValue="Toggle me on" />
</dsf:toggleButton>

We must be able to handle properties that reference components that have yet to have their dijit created. This is problem, for example, with the datagrid headerMenu property. The datagrid dijit does not initialize properly if the menu component referenced by the headerMenu property has yet to render its dijit creation code and therefore does not exist when the datagrid startup() is called.

Implement related interfaces as we will use Java service approach to handle theme issues.

it is the base class of all the mobile widgets

<dojo:textBox>
<dojoBehaviors:behaviorCopyValue event="change" source="@event" destination="result" />
</dojo:textBox>
<dojo:textBox id="result" />

In the above case, the result will be undefined.

I created a class named MobileTheme which inherits DojoTheme. It implements DeviceTheme logic and import common.css.
Note it is not a tag.

We missed to create the dijit.inlineEditBox

We need a new annotation valueholder. The ValueHolder 's base class is UIOutput. and it has value property. do not have validator or postbackhandler. the value can not be submitted.

All sample pages in our showcase except behaviors occurs an exception:
javax.el.ELException: /resources/showcase/usage.xhtml: Property 'tag_borderContainer' not found on type org.dojoserverfaces.showcase.bundle.ShowCaseResourceBundle.

Currently, our dsf:button will detect that if attribute action is not null, we will set button type to "submit" by default. There are two problems:

1. default value "submit" is not quoted, emitted scripts like "type":submit
2. I saw that the h:commandButton will also detect actionListener attribute, and do the same process as action, should we keep consistent with h:commandButton?

A ValueHolder should treat the valueProperty the same as a ValueEditor in that a component definition can override the default type used for the value property (e.g. BooleanCheckBox).

After project restructure, the uploader related behaviors' namespace is not "http://www.dojoserverfaces.org/core" but "http://www.dojoserverfaces.org/library/standard".

remove getRenderedClientIdById from BehaivorBase
Add getClientId into GridBehaviorBase and updateProgressBar classes.

As Bob said in the email. he created some defects for me. They are:
DefaultCell description is inadequate.
Theme Component description should cover context-param
Remove SyntaxHighlight component
StructureBase needs tag annotation removed

When assigned a literal (e.g. "10.0") to smallDelta like <dsf:numberSpinner smallDelta="10.0" />, you'll got an exception "javax.el.ELException: Cannot convert 10 of type class java.lang.String to class java.lang.Number".

Implement LibraryService related interfaces for Mobile Library to handle theme issues.

<dsf:dateTextBox id="dateTextBox" /> - The value property is not set, then NullPointException occurs.

We missed wrapping this widget in our dsf library standard (desktop).

Remove unused files in GridBehavior package

The download for dojoserverfaces-library-showcase-beta-0.0.1.war results in an error page like this:

<Error><Code>AccessDenied</Code><Message>Access Denied</Message><RequestId>3FAF2996A7B6A5FF</RequestId><HostId>1BaPDpmsLZiBI6RZ+qSh4JxmLTifvxx2ZKYgbJ644y6rcDX6ErDfO5VeEmsQVKta</HostId></Error>

Some implementation of DojoWidget like HorizontalRule/VerticalRule have a property named "container" which will be conflicted with "isContainer" in DojoWidget.

In the content pane sample, when set the href to "http://www.baidu.com", then click apply, the content pane display nothing which I meant to display the specified error message. And the loading indicator is missed.

The description of the broadcast behavior is inadequate. It needs a bit more detail and should be consistent with other behaviors and or components.

it is a ItemFileReadStore using a java collection as it source.

Make use of Java service approach to load dojo.js and/or common.js and theme support for separate libraries (Standard and Mobile libraries).

I found that the cellType 's requires can not be added. It is because the isSet method.
the Cell and View 's complexProperty is always return false. So it can not add the requires.
I would override the isSet and let it always return true.

Property.isSet missed javadoc, LibraryService related classes missed javadoc and copyright.

We find that some mobile container widget whose children 's type is limited. The children should be handle by the container.such as IconContainer(IconItem) and TabBar(TabBarButton) . we would add a new property to @container annotation named rendersChildren to show whether the container render its children or just as the usual container.we would override the getRendersChildren() and encodeChildren() methods

DateConverter is in the core project. it is used to convert java.util.Date, java.sql.Date and java.sql.Timestamp.
Refactored jsfDataModelReadStore. It is rendered a ItemFileReadStore and its data source is a java collection

As we will create a separate project for mobile, and there are some behaviors can be used in both desktop and mobile dsf components, so we need to separate these behaviors into a new library project.

I put the sample of toggle button together with other buttons, as their attributes are almost the same.

New package structure would be:
org.dojoserverfaces.mobile.component
org. dojoserverfaces.mobile.service
org.doj oserverfaces.mobile.property
org.dojoserverfaces. mobile.behaviors
...

In the Dojo API Documentation, "places" is a Number, but we used String in the NumberInputBase.class.

According to Dojo API documentation, widgets in a container should not call startup() itself.
http://dojotoolkit.org/reference-guide/quickstart/widgetHierarchies.html#id1