Hello.

Can i add facebook widgets to pallete?
Like facebook chat, comments and like button?

Right now the JavaScript logic in the doc set does nasty things with hyperlinks
to allow for nice URL referencing to other pages within the doc set, but it
messes up the ability to link within a page or link to pages outside of the doc
set.

Catch-all bug to make sure we are using image sprites to the maximum possible extent. We have some spriting already in place but haven't done everything yet.

The following steps describe the process I am taking in Maqetta:

1. Create new HTML file
2. Drop a DIV on the workspace (for this process I will call this DIV

3. Drop a Dojo Edge-to-Edge list in the DIV
4. Drop a new DIV on the workspace (for this process I will call this
   DIV 2)
5. Drop a Dojo button in the DIV
6. Create a new state called "Off"
7. For the Off state, click to close the eyes on DIV 1 and the Edge-
   to-Edge control, and the list items.
8. Create a click event for the button - select the Off state

View in the browser. Everything looks good, but when I click on the
button, nothing occurs.

I appreciate whatever help you can provide.

Thank you,
John

Currently, the New... menu in the application header area does not
contain icons. Which forces the user to read through each entry. Adding icons
will help with instant recognition of available actions.

Changes that should be made...

1. Icons should be added for each action
2. The word 'New' should be removed from the menu, since the word New invokes
   the actions.. its a bit redunnant

The menu should read as such..

New [ARROW]
[ICON] HTML File...
[ICON] CSS File...
[ICON] JavaScript File...

[ICON] File...

[ICON] Review...

(This might be fixed - this bug is logged to investigate to see if problem is still present. Here is the old bug report)

When running the Tutorial, current instructions tell people to move the overlay
empty ContentPane on top of the rest of the page, and then drag/drop elements
into that overlay ContentPane. However, when I try to drop a DIV into the
ContentPane, instead of going into the ContentPane, it pierces through the
ContentPane to underlying content and drops the new DIV there.

I suspect the ContentPane has no content, so nothing to receive the drop event.

User feedback: If the alignment buttons are used to align not just text but also buttons and such, should the alignment buttons be in their own "Alignment" section, rather than under "Text"?

This feedback can be generalized to the high-level task of reorganizing the grouping of properties in the properties palette to make more sense for common user requirements.

• New HTML File
• Add a BorderContainer with only left and center panes
• Add a TextBox to the center pane (visually, the one on the right)
• With TextBox still selected, drag the splitter (between the left and center
  panes) to the right by about 50 pixels

Result => Selection chrome on TextBox doesn't change location.

Could anybody build Maqetta from the latest github source repository
using Eclipse (Helios) on Mac OS X 10.6? By following the
documentation at https://github.com/maqetta/maqetta/wiki/Developer-Setup,
I couldn't build it. Especially configuring the OSGi framework looks
different from the doc.

I tried to select all available bundles, but Java is throwsing several
errors.

Finally, when I try to access via browser, I get the following 404

Once the page editor layout has been simplified, we should ensure that the
default layout is 25% for the left column (containing the views) and 75% for
the right area containing the page editing area. This aligns with the golden
rule to create a pleasing grid ratio to start working with.

Various cosmetic things in properties palette regarding spacing.

• The first and last (empty) table columns for each item in the Properties
  palette currently has width:15px. This is too much. Instead, set the leftmost
  column width to .5em and the rightmost column width to 1em.
• Also, right now the widgets are hardcoded within elements. Something to
  consider would be putting using a class definitions instead of hardcoding this
  with each TABLE element to allow tweaking the .5em and 1em values universally
  by changing a couple of properties within a CSS file.
• Each propertyExtra section right now is 36px (set via a hardcoded value in a element). This is too big and causes wasted space to the right of the textboxes, preventing the textboxes from using up all potential space. Can we change it to 24px? Again, if this could be moved to a CSS file instead of hardcoded, that would be better.
• The textbox for event properties right now don't take up the full potential
  width that they could. This is because there is an invisible propertyExtra
  section for the event properties. We should somehow get rid of this
  propertyExtra section for event properties. I'm pretty sure this can be
  accomplished by simply setting display:none on the appropriate element.
• The Common section type-in areas don't take up the full potential horizontal
  area. The TD that surrounds the INPUT elements are stretching, but the INPUT
  elements aren't stretching. I think that all that needs to happen is that the
  INPUT elements need to have width:100% (seems to work in debugger).

these exceptions started appearing in the log after we installed the latest
build on maqetta.org:

java.lang.IllegalStateException: [0] Bad JSON starting character '.'
at org.davinci.server.util.JSONReader.error(Unknown Source)
at org.davinci.server.util.JSONReader.parseValue(Unknown Source)
at org.davinci.server.util.JSONReader.parse(Unknown Source)
at org.davinci.server.util.JSONReader.read(Unknown Source)
at org.davinci.server.internal.command.Download.handleCommand(Unknown
Source)
at org.davinci.server.DavinciCommandServlet.doGet(Unknown Source)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at org.davinci.server.DavinciCommandServlet.service(Unknown Source)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.eclipse.equinox.http.registry.internal.ServletManager$ServletWrapper.service(ServletManager.java:180)
at
org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61)
at
org.eclipse.equinox.http.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:28)
at
org.mortbay.servlet.UserAgentFilter.doFilter(UserAgentFilter.java:78)
at org.mortbay.servlet.GzipFilter.doFilter(GzipFilter.java:131)
at
org.eclipse.equinox.http.registry.internal.FilterManager$FilterWrapper.doFilter(FilterManager.java:173)
at
org.eclipse.equinox.http.servlet.internal.FilterRegistration.doFilter(FilterRegistration.java:71)
at
org.eclipse.equinox.http.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:25)
at
org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:130)
at
org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:68)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.eclipse.equinox.http.jetty.internal.HttpServerManager$InternalHttpServiceServlet.service(HttpServerManager.java:318)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:924)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)

404 when requesting one a file while bringing up theme editor
this file: http://maqetta.org:55555/maqetta/user/[email protected]/ws/workspace/themes/claro/images/titlebar.png

Browser type: Google Chrome
Browser version:8.0
OS and OS Version: Windows XP
All steps necessary to reproduce the issue:

  1. Drag and drop the dojo TabContainer widget to designer editor. The HTML code will add below code:
  @import "./lib/dojo/dojo/resources/dojo.css";

  2. Delete the TabContainer widget.

  3. repeat the 1 step. The duplicated code generated:
  @import "./lib/dojo/dojo/resources/dojo.css";
  @import "./lib/dojo/dojo/resources/dojo.css";

Reporter: Jawf Lee([email protected])

I noticed that the inline edit box is placed within the editor iframe (which
makes sense). But this has the side effect that it can be clipped (partially
hidden) when opened near the edge of the iframe, or when moving it to a
different area.

It would be nice if the inline edit box actually hovered above the whole app,
so (if necessary) it could be moved anywhere on the whole page, even over some
other views.

Not sure how easy this would be to accomplish, especially to have the tooltip
dialog "shark fin" point to the correct widget.

Related to this - the selection chrome really shouldn't be in the user's iframe
but in the app's frame, just properly positioned. Right now there are bugs
where if the user's content (or Dojo for that matter) posts a DOM element with
a high z-index, then the selection chrome gets obscured. By putting it in the
app's iframe, we can ensure that the selection chrome is above anything in the
user's iframe.

Apparently, we need to pass something in for the version parameter when doing a build, e.g.

./build.sh profile=standard version=$1 releaseName=$buildName cssOptimize=comments.keepLines optimize=shrinksafe.keepLines action=release

If we check in built code (see issue #16) this is no longer an issue. @jhpedemonte, perhaps this only matters for the user library Dojo?

New File... doesn't have a toolbar. Either we need to add a toolbar, or remove the command. As is, not particularly useful since there is no way to save the new file you just created.

Updated 2012-03-13: Allow users to edit arbitrary text files, not just .html, *.js and *.css. Need to add a toolbar for such files, with at least *Save and Save As.

There are a few differences between the claro that ships with Dojo 1.5 and the
version of claro that we ship with Maqetta. We need to have a long-term
strategy for how to deal with the small differences that we have had to
introduce.

Of course, the ultimate goal is that we have to make zero changes, but there
might be short-term challenges that prevent the ideal from happening right
away.

Worst case is that the deltas are not documented (i.e., no docs on what changes
were made and why) and not automated (i.e., changes are done by hand, and have
to be reintroduced into new versions of Dojo by hand).

When I activate the UI in the properties palette that shows the CSS cascade (by
clicking on the right pointing arrow to the right of any property), Firebug
shows 14 empty DIVs between the TABLE that holds the title bar (Apply to:, Show
all rules, X) and a second TABLE that holds all of the radio buttons. What's up
with that?

I'm not sure if there are always 14 empty DIVs. Maybe sometimes zero, maybe
sometimes more.

What I was doing at the time was taking a page that only had a single Dojo
button and repeatedly changing the 'color' property, assigning to element.style
(the default).

We have to figure out what to do with widgets from jQuery, YUI and other
toolkits when the user wants to use wireframe mode. One possible strategy would
be to put a metadata field for each widget that says something like
supportsWireframe:true|false, and then only show widgets where
supportsWireframe:true. What do you think of this?

Currently, previewing something will open a new window, regardless if an existing one is open already. Wordpress admin panel handles it better - if a window is already open, it will refresh that tab.

It'd be nice to have this behavior here as well to cut down on closing the old and obsolete preview widows.

Need to figure out what to do about copy/paste/icons in split view. The code has no good way of guessing which pane the user was last working in.

One idea I have so far is to have separate toolbars for design and source, and in split view you would get two toolbars, with the result that cut/copy/paste icons show up twice in split view. But that's a little weird because you probably would only want certain buttons (undo, redo, save, ...) on a single toolbar and not replicated on two toolbars.

No keyboard accelerators on iPad, so we will probably need 2 toolbars for iPad.

A variation on the 2-toolbar approach is we also add some styling support to the toolbars (e.g., darker gray border for the toolbar that isn't active?) to show which pane will be the target for keyboard accelerators (e.g., Ctl-C, Ctl-V). Another styling option is to post a small icon (little keyboard) on the toolbar that is the target for keyboard accelerators.

(1) There is a mysterious DIV between the 'height' property and the checkbox
for show min/max. Why is that DIV there? Maybe it belongs after the min/max
checkbox to visually separate the width/height properties from everything else
in the palette? One option would be to simply remove this DIV. (I don't think
it does anything except provide spacing)

(2) Can we center-align the min/max checkbox? Right now it is left-justified

Also, can the order of the properties be:
min-width
max-width
min-height
max-height

I create a sticky note and accepted default content ("Enter note"). With the
sticky note selected, I clicked on the Cut icon and then performed a paste
operation (click on Paste icon and then click on canvas). A sticky note appears
but there is nothing inside of it.

www.google.com/webfonts offers hundreds of libre-licensed fonts for download and web use via Google's Web Font API service.

It would be great to integrate the Google Web Font service into Maqetta :)

Particularly for absolute layout:

• guidelines appear as candidate snap points to align with other widgets as you drag items around on canvas
• alternatively, have items snap to a grid at fixed intervals?

see bugzilla bug 4823

The Sash affordances should be 6 pixels in width (for vertical sashes) and
always show a line as a visual texture for dragging to re-size the views
vertically or horizontally.

Some nitpicky fixes to menus on Properties palette:

• max-width/max-height: right now it shows options of ["auto","0px"]. Instead,
  should show ["auto","100%","200px"].
• display: should be a ComboBox instead of a simple menu () so that users can type in values that differ from the four values we show in menu. For example, once in a while the user might want to set display:table-cell. (It's part of one of the standard web tricks for achieving vertical alignment) opacity: menu shows ["0","" (empty string), "0.5", "1.0"]. The empty string option should be the first, not the second. Also, in this case, I think it would be better to show "0.0" rather than "0". box-shadow not implemented yet (see bug 6658) margin and padding shortcut properties show ["0","1em"] but the margin-* and padding-* properties show ["0px","1em"]. Let's make them consistent and have everything show ["0px","1em"] border-{top|right|bottom|left} (the "sides") should show the same menu options as 'border': ["none","1px solid black"] border-style isn't showing the correct values. Should show all possible values for border-style from the CSS spec (sorry, changed my mind), starting with ["none","solid","dotted","dashed"], but also including at the end the other values listed at http://www.w3.org/TR/CSS21/box.html#value-def-border-style. If possible, would be good to put a separator between the common values and these other values that are hardly ever used. Same thing for border-{top|right|bottom|left}-style Note that border-{top|right|bottom|left}-color aren't bringing up color palette (sorry, changing my mind again) font-weight should show all of the values at http://www.w3.org/TR/CSS21/fonts.html#propdef-font-weight. If possible, would be good to put a separator between the common values and these other values that are hardly ever used. vertical-align needs to be a ComboBox because this property allows users to type in numeric values. Not used very often, but this is still an option.

Tasks:

• Get a working WAR from M6 release (pre-Orion).
• Manually create WAR from nightlies (post-Orion).
• Fix build to output WAR file.

Right now, to do theme editor, a user first clones one of the standard themes
(e.g., claro) and then brings up the theme editor to change the CSS files in
the clone.

I'm wondering if instead of changing the theme CSS files, it might be better to
store incremental CSS style rules into a delta CSS file that contains overrides
to the base theme.

Any instant reactions to this idea? My instincts are that this is a better
approach and what we should have been doing from the beginning, but I still
need to think things through from a user perspective. From an implementation
perspective, one reason for optimism that a delta approach is achievable is
that we funnel all property palette changes into a small number of style
modification commands in order to hook into the undo system. Therefore, maybe
the code changes would be isolated into only a few places. (???)

One concern: what if the base theme changes, say due to an upgrade? This may
cause issues if all that was saved was the delta.

The New File dialog doesn't always pick the correct parent folder.

I created a new folder and selected it, then selected New File --> dialog still
listed "." as parent folder, even though "folder1" was selected.

Dismissed New File dialog, clicked again on "folder1" and reopened New File
dialog -- now it correctly showed "folder1" as parent.

Dismiss dialog, selected a file in top level (i.e. app.css) and opened New File
dialog -- still showed "folder1" as parent, instead of ".".

Dismiss dialog, select "folder1", reopen New File dialog -- now shows "." as
parent folder, instead of "folder1".

http://dojo-toolkit.33424.n3.nabble.com/Editor-in-FireFox-throwing-an-error-td1391910.html

sample file1.html

<!DOCTYPE html>
<html>
<head>
<title>Untitled</title>
<style type="text/css">
@import "themes/claro/claro.css";
@import "app.css";
@import "./lib/dojo/dojo/resources/dojo.css";
@import "./lib/dojo/dojo/resources/dojo.css";
</style>
<script type="text/javascript" src="./lib/dojo/dojo/dojo.js"
djConfig="parseOnLoad: true"></script>
<script type="text/javascript">
dojo.require('dijit.form.Button');
dojo.require('dijit.layout.BorderContainer');
dojo.require('dijit.layout.ContentPane');
dojo.require('dijit.layout.TabContainer');
dojo.require('dijit.layout.AccordionContainer');
dojo.require('dijit.TitlePane');
dojo.require('dijit.Toolbar');
dojo.require('dijit.MenuBar');
dojo.require('dijit.PopupMenuBarItem');
dojo.require('dijit.MenuItem');
dojo.require('dijit.Menu');
dojo.require('dijit.form.TextBox');
dojo.require('dijit.form.ComboBox');
dojo.require('dijit.form.CheckBox');
dojo.require('dijit.Calendar');</script>
<script src="maqetta/States.js"></script>
<script src="maqetta/maqetta.js"></script>
</head>
<body class="claro lotusui" dvFlowLayout="true" data-davinci-ws="collapse"
id="myapp">
 <input type="button" dojoType="dijit.form.Button" disabled="false"
intermediateChanges="false" label="Button"></input>
 <div dojoType="dijit.layout.BorderContainer" design="sidebar" persist="false"
gutters="true" style="width: 100%; height: 100%; min-width: 1em; min-height:
1em;">
   <div dojoType="dijit.layout.ContentPane" extractContent="false"
preventCache="false" preload="false" refreshOnShow="false" region="top"
splitter="true" style="height: 50px;" doLayout="false"><span
dojoType="dijit.layout.AccordionContainer" style="width: 100%; height: 100%;
min-width: 1em; min-height: 1em;">
<div dojoType="dijit.layout.ContentPane" title="Pane 1" extractContent="false"
preventCache="false" preload="false" refreshOnShow="false" selected="true"
closable="false" style="width: 884px;" doLayout="false"></div>
<div dojoType="dijit.layout.ContentPane" title="Pane 2" extractContent="false"
preventCache="false" preload="false" refreshOnShow="false" selected="true"
closable="false" style="width: 884px; height: 1px;" doLayout="false"></div>
</span></div>
   <div dojoType="dijit.layout.ContentPane" extractContent="false"
preventCache="false" preload="false" refreshOnShow="false" region="bottom"
splitter="true" style="height: 50px;" doLayout="false">
    <div dojoType="dijit.layout.ContentPane" title="Pane" doLayout="false"
style="width: 250px; height: 250px;"></div>
  </div>
   <div dojoType="dijit.layout.ContentPane" extractContent="false"
preventCache="false" preload="false" refreshOnShow="false" region="left"
splitter="true" style="width: 50px;" doLayout="false"><span
dojoType="dijit.TitlePane" title="Pane" extractContent="false"
preventCache="false" preload="false" refreshOnShow="false" open="true"
style="width: 100%; min-width: 1em;"></span>
<input type="text" dojoType="dijit.form.TextBox"></input>
<select dojoType="dijit.form.ComboBox" value="Item 1" disabled="false"
readOnly="false" intermediateChanges="false" trim="false" uppercase="false"
lowercase="false" propercase="false" required="false">
<option dvwidget="html.option" value="Item 1" selected="true">
  Item 1</option>
<option dvwidget="html.option" value="Item 2" selected="false">
  Item 2</option>
<option dvwidget="html.option" value="Item 3" selected="false">
  Item 3</option>
</select>
</div>
   <div dojoType="dijit.layout.ContentPane" extractContent="false"
preventCache="false" preload="false" refreshOnShow="false" region="right"
splitter="true" style="width: 50px;" doLayout="false"></div>
   <div dojoType="dijit.layout.ContentPane" extractContent="false"
preventCache="false" preload="false" refreshOnShow="false" region="center"
splitter="false" doLayout="false"><span dojoType="dijit.layout.TabContainer"
style="width: 100%; height: 100%; min-width: 1em; min-height: 1em;"
controllerWidget="dijit.layout.TabController">
<div dojoType="dijit.layout.ContentPane" title="Tab 1" extractContent="false"
preventCache="false" preload="false" refreshOnShow="false" selected="true"
closable="false" style="width: 892px; height: 140px;" doLayout="false"><span
dojoType="dijit.Toolbar">
<input type="button" dojoType="dijit.form.Button" tabIndex="-1"
disabled="false" intermediateChanges="false" label="Button 1"></input>
<input type="button" dojoType="dijit.form.Button" tabIndex="-1"
disabled="false" intermediateChanges="false" label="Button 2"></input>
<input type="button" dojoType="dijit.form.Button" tabIndex="-1"
disabled="false" intermediateChanges="false" label="Button 3"></input>
</span><span dojoType="dijit.MenuBar" tabIndex="0"><span
dojoType="dijit.PopupMenuBarItem" label="Menu 1" disabled="false"><span
dojoType="dijit.Menu"><span dojoType="dijit.MenuItem" label="Menu Item
1.1"></span><span dojoType="dijit.MenuItem" label="Menu Item 1.2"></span>
</span>
</span><span dojoType="dijit.PopupMenuBarItem" label="Menu 2"
disabled="false"><span dojoType="dijit.Menu"><span dojoType="dijit.MenuItem"
label="Menu Item 2.1"></span><span dojoType="dijit.MenuItem" label="Menu Item
2.2"></span>
</span>
</span>
</span>
<input type="checkbox" dojoType="dijit.form.CheckBox"></input>
<input dojoType="dijit.Calendar" datePackage="dojo.date"
value="2011-04-15"></input>
</div>
<div dojoType="dijit.layout.ContentPane" title="Tab 2" extractContent="false"
preventCache="false" preload="false" refreshOnShow="false" selected="true"
closable="false" style="width: 892px; height: 157px;" doLayout="false"></div>
</span></div>
 </div>
</body>
</html>

Just checking out maqetta for the first time... The editor displays as expected, but when I open a page or drop a control on a new page, nothing happens. In Firefox 4 and Chrome 10, on Vista. Pretty much default settings in both, as far as security, popups, etc.

The source is updated during an undo/redo, but not the nodes visible on the
tree. There were a couple of kludges required to get the visual editor to
update when modifying the store data during input:

    replaceTreeStoreData: function(tree, data) {
            var model = tree.model;
            var store = model.store;

            // Kludge to force reload of store data
            this.replaceStoreData(store, data);

            // Kludge to force model update
            model._requeryTop();


    replaceStoreData: function(store, data) {
            store.clearOnClose = true;
            store.data = data;
            store.close();
            store.fetch({
                    query: this.query,
                    queryOptions:{deep:true}, 
                    onComplete: dojo.hitch(this, function(items){
                            /*for (var i = 0; i < items.length; i++) {
                                    var item = items[i];
                                    console.warn("i=", i, "item=", item);
                            }*/
                    })
            });
    },

I've tried to do something similar when an undo is performed, but it doesn't
work. For one thing, the undo doesn't update the store attribute on the model,
so it still points to the old store. But even when corrected to point to the
new store, the hack still doesn't work because the model wasn't designed to
have its store replaced. Seems to be a real conflict here between how Maqetta
requires modifications be made and what dijit requires for Trees.

One possible solution: If we didn't have to delete/recreate the data store
widget when performing a ModifyCommand, then the model would point to the same
old store reference, and we'd just need to trigger the model update as before.
But the current command framework seems to depend heavily on widget creation to
update the source nodes in the model.

Another possible solution: Recreate the entire tree when updating its store.
The problem is I don't know of a way to do this using the command stack instead
of TreeCreateTool and still end up with all the right connections.

Other thoughts?

------- Comment #1 From Jon Ferraiolo 2010-08-23 10:34 [reply] -------

It seems we have to go one way or the other with regard to Undo and
ModifyCommand. Either we try our best to keep the old widget around so we can
do incremental updates, or we recreate the widget entirely from scratch.

When we looked at this issue last fall when worrying about some other issue (I
believe it was 'id' attribute), we concluded that there were always going to be
cases where we had to recreate the widget entirely from scratch, so we decided
to get that code path working robustly, and then we would consider an
alternate, faster code path down the road. I think the same analysis and logic
applies to this problem. Therefore, my instincts are that we should work
towards a programming solution that recreates the binding to the data store
when an undo operation occurs.

Related to this issue is the following bug I wrote up yesterday:

http://gila.austin.ibm.com/bugzilla/show_bug.cgi?id=6353

In that bug report, I argue that we should move most of the widget creation
logic out of widget.createWidget(), which happens before the command stack
flushing, into context.attach(), which executes during command stack flushing.
My argument is that this architecture will provide more flexibility down the
road, such as potentially allowing automated test creation via record/playback,
persisting undo across sessions, and enable simultaneous document editing by
multiple users.

these WARN:ERRORs started showing up in the log after we installed the new
build on maqetta.org. they are repeated for many different files, but all were
under a "TryIt" guest account.
2011-04-28 16:24:03.681:WARN::ERROR:
/maqetta/user/_Guest_1303986828715/ws/workspace/welcome
2011-04-28 16:24:08.901:WARN::ERROR:
/maqetta/user/_Guest_1303986828715/ws/workspace/welcome
2011-04-28 16:55:52.739:WARN::ERROR: /maqetta/cmd/download
2011-04-28 19:11:16.734:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dijit/layout/StackController.js
2011-04-28 19:11:17.373:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dijit/layout/ContentPane.js
2011-04-28 19:11:16.734:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dijit/layout/StackContainer.js
2011-04-28 19:11:29.081:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dijit/MenuSeparator.js
2011-04-28 19:11:29.081:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dijit/CheckedMenuItem.js
2011-04-28 19:11:31.224:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dojo/regexp.js
2011-04-28 19:11:31.325:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dojo/html.js
2011-04-28 19:11:31.325:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dijit/layout/ScrollingTabController.js
2011-04-29 00:12:54.695:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dojo/date.js
2011-04-29 00:12:59.098:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dijit/form/TextBox.js
2011-04-29 00:13:01.366:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dojo/date/locale.js
2011-04-29 00:13:01.368:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dojo/cldr/supplemental.js
2011-04-29 00:14:28.730:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dijit/Calendar.js
2011-04-29 00:14:30.353:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/maqetta/maqetta.js
2011-04-29 03:15:40.028:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dojo/dojo.js
2011-04-29 03:16:49.041:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dijit/dijit.js
2011-04-29 03:53:55.613:WARN::ERROR:
/maqetta/user/_Guest_1303639043877/ws/workspace/Sample1.html
2011-04-29 04:59:24.572:WARN::ERROR: /maqetta/cmd/saveFile
2011-04-29 04:59:30.890:WARN::ERROR: /maqetta/cmd/saveFile
2011-04-29 04:59:37.812:WARN::ERROR: /maqetta/cmd/saveFile
2011-04-29 04:59:43.445:WARN::ERROR: /maqetta/cmd/saveFile
2011-04-29 05:12:35.718:WARN::ERROR: /maqetta/cmd/deleteResource
2011-04-29 05:12:46.516:WARN::ERROR: /maqetta/cmd/deleteResource
2011-04-29 05:17:35.708:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dojo/cldr/nls/en/gregorian.js
2011-04-29 05:17:35.709:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dijit/PopupMenuItem.js
2011-04-29 05:17:35.710:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dijit/form/Button.js
2011-04-29 05:17:35.821:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dijit/layout/_TabContainerBase.js
2011-04-29 05:17:36.334:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dojo/cookie.js
2011-04-29 05:17:36.335:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dijit/Menu.js
2011-04-29 05:17:36.435:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dijit/nls/loading.js
2011-04-29 05:17:53.487:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dijit/layout/TabContainer.js
2011-04-29 05:17:53.588:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dijit/form/ToggleButton.js
2011-04-29 05:17:53.588:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dijit/layout/TabController.js
2011-04-29 05:17:53.895:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dijit/_HasDropDown.js
2011-04-29 05:17:54.918:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dijit/MenuItem.js
2011-04-29 05:17:56.176:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dijit/nls/common.js
2011-04-29 05:17:56.188:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dojo/i18n.js
2011-04-29 05:17:56.285:WARN::ERROR:
/maqetta/user/_Guest_1303911791900/ws/workspace/lib/dojo/dijit/_KeyNavContainer.js
2011-04-29 09:07:50.645:WARN::ERROR: /maqetta/cmd/deleteResource
2011-04-29 09:07:52.265:WARN::ERROR: /maqetta/cmd/rename
2011-04-29 09:07:52.302:WARN::ERROR: /maqetta/cmd/loadFile
2011-04-29 09:08:04.388:WARN::ERROR: /maqetta/cmd/loadFile

followed by this exception:

java.lang.NullPointerException
at org.davinci.server.DavinciPageServlet.handleLibraryRequest(Unknown
Source)
at org.davinci.server.DavinciPageServlet.handleWSRequest(Unknown
Source)
at org.davinci.server.DavinciPageServlet.doGet(Unknown Source)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.eclipse.equinox.http.registry.internal.ServletManager$ServletWrapper.service(ServletManager.java:180)
at
org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61)
at
org.eclipse.equinox.http.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:28)
at
org.mortbay.servlet.UserAgentFilter.doFilter(UserAgentFilter.java:78)
at org.mortbay.servlet.GzipFilter.doFilter(GzipFilter.java:154)
at
org.eclipse.equinox.http.registry.internal.FilterManager$FilterWrapper.doFilter(FilterManager.java:173)
at
org.eclipse.equinox.http.servlet.internal.FilterRegistration.doFilter(FilterRegistration.java:71)
at
org.eclipse.equinox.http.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:25)
at
org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:130)
at
org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:76)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.eclipse.equinox.http.jetty.internal.HttpServerManager$InternalHttpServiceServlet.service(HttpServerManage
r.java:318)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:924)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)

If the user selects a widget in page designer using the outline then switches
pages the selection box remains from the previous page selection

Hi,

I didn't have a chance to download the program to provide patches, but I did come across the following vulnerabilities.

File browsing:
http://maqetta.org:55555/maqetta/cmd/loadFile?path=

Directory Transversal:
http://maqetta.org:55555/maqetta/cmd/listFiles?path=
http://maqetta.org:55555/maqetta/cmd/findResource?path=&ignoreCase=true

Best Regards,

Jason Brumwell

As reported by @JonFerraiolo:

(Maybe piling too much on Adam - maybe Brad or Bill could look at this one)

• New HTML file
• Add a DIV
• Set size to w=h=300px
• Add a TabContainer inside the DIV. (TabContainer defaults to 100%/100%, so it
  fills the DIV)
• Save, close, reopen
• In Outline palette, select the DIV
• Pull on resize handles to make the DIV wider
  Result=> TabContainer does not resize
• Save, close, reopen
  Result=> TabContainer is now the right size

Maybe we aren't calling the resize method for children of DIV?

see bugzilla bug 7270

Right now, we have duplicate versions of Dojo: one for the runtime and one for the user library. This is an artifact of how the user library code is set up. We should amend that code to make use of the Dojo version used by the workbench, so we cut down on the duplication.

Later, we'll probably allow multiple versions of libraries, but at least one of those versions will be the Dojo used by the workbench.

While running maqetta on my desktop, the OSGi console shows the following warning:
Library file not found! :WebContent/yui
Library file not found! :WebContent/jquery-ui-1

I could get rid of this warning by making the following changes:
1. /davinci.yui_2_6_0/plugin.xml
Replace all '2.8.2r1' phrases with '2.6.0'
2. /davinci.jqueryui_1_8/plugin.xml
Replace all '1.8.11' phrases with '1.8'

I've found that multiple users haven't been aware that Maqetta is
continuously auto-saving their edits to the server (so that if the user
refreshes Maqetta or the browser crashes, they will be able to restart where
they left off). They think they have to hit Save to make sure they don't lose
their edits.

Can we add something to the tutorials where we tell the user we auto-save and
then show them this is true by having them issue a Ctrl-R in one of the
tutorials to show that the changes they made are still there?

In the themes, can i use other user themes?

We need to simplify the initial UI of the page editor to make it look less like desktop IDEs (e.g., Eclipse) and have a streamlined and simpler UI. For example, fewer palettes show initially, and all palettes are on the left side.

This UI reorg needs to take into account issues associated with non-desktop platforms, such as tablets.

The '/maqetta/cmd/findResource' command is throwing "java.io.CharConversionException: Not an ISO 8859-1 character: ?" with a WARN message.

Content in the user space is unoptimized. Would it make sense to use something like zazl's optimizer to dynamically combine HTTP requests, concatenate responses for JS and CSS, reduce whitespace and symbols, etc.? This seems like it may be a good fit for preview, perhaps even for users to deploy their apps. An AMD-based solution may be more generic and not require any Dojo linkage.

For the Visual Editor, the set of resources is generally not known, as individual widgets can be chosen at will. However, for more complex widgets like dijit.Editor which itself comprises a few dozen HTTP hits, combining those requests may be a significant gain.

The URL created when opening preview-in-browser contains the user's email address. Look into changing that so email address isn't used. Perhaps each user can have a unique number associated with their workspace, and that is used in the URL instead of email.

dvFlowLayout -> data-davinci-flow-layout
dojoType -> data-dojo-type, djConfig -> data-dojo-config (requires Dojo 1.6 -- see #16)
oawidget -> data-oaa-type
dvWidget -> ?

We should upgrade to the current Dojo release (1.6 at the time of filing) or perhaps skip straight to trunk in order to work with the latest dojox.mobile and AMD functionality. The latter carries risk, as the code is in flux right now. I'll try this on a branch.

Both the workbench code and the user library must be upgraded separately.