Creating visual WebApps with Joose

[Tom]

Hey there,

I do apologize for the amount of posts I made today, but then again I
have a lot of questions.

I'm trying to create a web application using Joose as my programming
structure (OOP).

Now, my app has quite a lot of logic that are related to visuals. I
wonder how I should handle this. Most people use a MVC pattern in
platforms like flash, is this suitable for Joose?

Anyway, at the moment I have the following:

- Main.js
- Interface/MainHandler.js
- Interface/MainPageStructureRole.js
- Interface/Buttons/NewSource.js

This is what it looks like:

//Main: handles main application logic, acts as an entry point
Class("Main", {
use : "Interface.MainHandler",

//static
my : {
methods : {
//called before DOM is ready
initBeforeDOMReady : function() {},

//called after DOM is ready
initAfterDOMReady : function() {
console.log("Init after dom ready.");

//load main interface
Interface.MainHandler.load();
}
}
}
});

Class("Interface.MainHandler", {
use : "Interface.Buttons.NewSource",

does : ["Interface.MainPageStructureRole",
"Interface.MainPageCSSRole"],

my : {
has : {
isLoaded : {is : "rw", init : false},
newSourceButton : {is : "rw", init : null}
},

methods : {
load : function() {
console.log("Interface.MainHandler load.");
if (this.getIsLoaded()) throw "Interface.MainHandler has already
loaded.";

//set main page structure
this.resetMainPageStructure();

//set main page css
this.resetMainPageCSS();

//load element: Buttons.NewSource
this.newSourceButton = new Interface.Buttons.NewSource();
this.newSourceButton.load(this.mid1Element,
this.onSourceButtonClick);

//loaded
this.setIsLoaded(true);
},

onSourceButtonClick : function() {
console.log(this);
}
}
}
});

Role("Interface.MainPageStructureRole", {
my : {
has : {
bodyElement : {is : "rw", init : null},
top1Element : {is : "rw", init : null},
mid1Element : {is : "rw", init : null},
mid2Element : {is : "rw", init : null},
mid3Element : {is : "rw", init : null},
bot1Element : {is : "rw", init : null}
},

methods : {
resetMainPageStructure : function() {
//set body
this.bodyElement = $("body")[0];
jQuery(this.bodyElement).html("");

//remove existing elements
this.top1Element = null;
this.mid1Element = null;
this.mid2Element = null;
this.mid3Element = null;
this.bot1Element = null;

//create new elements
this.top1Element = $("<div/>")[0];
this.mid1Element = $("<div/>")[0];
this.mid2Element = $("<div/>")[0];
this.mid3Element = $("<div/>")[0];
this.bot1Element = $("<div/>")[0];

//add to body in order
$(this.bodyElement).append(this.top1Element);
$(this.bodyElement).append(this.mid1Element);
$(this.bodyElement).append(this.mid2Element);
$(this.bodyElement).append(this.mid3Element);
$(this.bodyElement).append(this.bot1Element);
}
}
}
});

Class("Interface.Buttons.NewSource", {
after : {
initialize : function(params) {
console.log("Interface.Buttons.NewSource initialize.");
}
},

has : {
isLoaded : {is : "rw", init : false},
domElement : {is : "rw", init : null}
},

methods : {
load : function(parentElement, clickCallback) {
if (!parentElement) throw "Load requires parentElement.";
if (this.getIsLoaded()) throw "Button has already loaded.";

//set dom element
this.setDomElement(jQuery('<input type="button" value="New
Source"/>')[0]);

//add to parent
jQuery(parentElement).append(this.getDomElement());

//set event listener
thisButton = this;
jQuery(this.getDomElement).click(function() {
clickCallback();
});

//loaded
this.setIsLoaded(true);
},

unload : function() {
if (!this.getIsLoaded()) throw "Button has not loaded yet.";
if (!this.getDomElement()) throw "No DomElement was set.";

//remove dom element
jQuery(this.getDomElement()).remove();
this.setDomElement(null);

//unloaded
this.setIsLoaded(false);
}
}
});

-- That was a lot of code. Sorry. --

Anyway, as you can see I am doing some things that I probably shouldn't
do. For example, look at the MainPageStuctureRole.js file. This probably
isn't what roles are supposed to do right?

Basically, I'm looking for a way to create webapps where visuals and
logic are separated in an easily maintainable OOP way.

If anyone has any suggestions/comments that'd be appreciated.

- Tom

[Nickolay Platonov]

On Thu, Nov 11, 2010 at 6:39 PM, Tom <tomm...@gmail.com> wrote:

Now, my app has quite a lot of logic that are related to visuals. I
wonder how I should handle this. Most people use a MVC pattern in
platforms like flash, is this suitable for Joose?

Of course. MVC is just a pattern. General recommendations:

- Do not mix Model and View. That is, create a Model - set of classes, which represents
the logic from your data domain, but they *do not know anything* about the DOM.
Model should be totally self-contained and covered with tests.

- Create a set of Views - widgets classes, which have the instances of Model as attributes
and renders them. Views should also react on events in Model and re-render any changes.

- Mix Model and View in Controllers.

Thats quite abstract recommendations, hopefully it make sense.

Regards, Nickolay

[Sir Robert Burbridge]

Please take all of this as constructive criticism =)

A couple of tips for better organization of your modules:

Modules should be named for what they do or provide, not what they are.

Your module, "Interface.MainPageStructureRole" probably doesn't actually provide a Role (that is, it probably doesn't generate a role and return it).  It certainly doesn't do a role, since that doesn't mean anything =)

When a class "consumes" a role (that's what classes do with roles), it is effectively making the statement "This class behaves as though it were [a]  ___________".

For example, let's take a class hierarchy like this:

Interface.Notice
Interface.Notice.Info
Interface.Notice.Warning
Interface.Notice.Error

The Interface.Notice class is a base class that describes what a general notice looks like; perhaps with some properties common to all notices:

Class("Interface.Notice", {
  // Inherit from some greater class that handles basic ability to display, etc.
  // with methods like show(), hide(), etc.
  use: "Interface.ContentPanel",
  my: {
    has: {
      content: {is: "rw"}
    , title:   {is: "rw"}
    , icon:    {is: "rw"}
    , timer:   {is: "rw", init: 3000}
    }
  , methods: {
      // Some methods that all notices should share.
    }
  }
})

Then you might declare the sub-classes this way:

Class("Interface.Notice.Info", {
  // Inherit from some greater class that handles basic ability to display, etc.
  // with methods like show(), hide(), etc.
  use: "Interface.Notice",
  my: {
    has: {
      icon:    {is: "rw", default: "ui-icon ui-icon-info"}
    }
  , methods: {
      // Some methods only "Info" notices should have, such as
    }
  }
})

Now, perhaps there are a bunch of things on your site that people can tweet about on twitter; some by clicking, some by drag-and-drop, whatever (News elements, poll results, etc.).  You realize that you want people to be able to tweet these info items (but not errors or warnings).  You have four main options:

1. Write custom tweet code for each object that can be tweeted.  (bad idea)
   
2. Write a super class like "Interface.Twitter" and inject it into your inheritance chain somewhere (terrible idea)
3. Write UI-level code (such as with jQuery) that goes and modifies various page elements on load (bad idea).
   
   
4. Define roles! (good idea)
   

Role("Tweetable", {
  // Require that any class that consumes this role needs to provide a
  // method ._tweetable_content() that returns a string to tweet.
  requires: ["tweetable_content"],

  my: {
    methods: {
      tweet: function () {
        var tweet = this._tweetable_content()
        // Now call twitter however you want to...
        ...
      }
    }
  }
})

Since you only want Info items to be tweetable, you might modify the class this way:

Class("Interface.Notice.Info", {
  // Inherit from some greater class that handles basic ability to display, etc.
  // with methods like show(), hide(), etc.
  use: "Interface.Notice"
, does: [Tweetable]
, my: {
    has: {
      icon:    {is: "rw", default: "ui-icon ui-icon-info"}
    }
  , methods: {
      tweetable_content: function () { return this.content() }
      // Some methods only "Info" notices should have
    }
  }
})

You could mark any number of objects as tweetable, then just tie in a "click" event (or whatever) to the obj.tweet() call.

I said before that when a class "consumes" a role (that's what classes do with roles), it is effectively making the statement "This class should behaves as though it were [a]  ___________".


The "TwitterRole" name would make this sentence read:

"This class behaves as though it were a TwitterRole".

Which doesn't really tell you anything descriptive.  What you want is:

"This class behaves as though it were Tweetable".

which is nice and descriptive.






Code structures (modules, functions, etc) should be designed around the concept of re-use.

As an aside, your classes have a similar non-semantic naming issue.  For example, I highly doubt that "Interface.Buttons.NewSource" is intended to create a new interface buttons of type NewSource (if so, something's probably wrong =)

Really, you probably just want Interface.Button (not "buttons" since the constructor probably doesn't return a set of buttons, but a single button).  If you want to create a new button that acts as a "new source" button, you should just instantiate a generic button with the parameters it needs to create the "new source" (whatever that is).

If you find yourself creating a lot of "new source" buttons, then make a "_create_button_newSource" function that generates "new source" buttons for you; classes should define *generic* behavior.


-Sir

--
You received this message because you are subscribed to the Google Groups "Joose" group.
To post to this group, send email to joos...@googlegroups.com.
To unsubscribe from this group, send email to joose-js+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joose-js?hl=en.

[Tom]

Hi Robert,

Thanks for your help. I realize that what I have at this moment makes no
sense at all, which is why I posted.

Anyway, your feedback really helps. However, while I do understand the
purpose of a role in your specific twitter example, I cannot see how
this can be used in many cases. Why would this replace multi
inheritance?

For example, I have a general UIHandler class. This handles the main
interface. It'd have to do a lot of things, which would create huge
functions. This is why I put the PageStructure etc. in a Role. This is
not the purpose of a Role though. So, how should I do these kind of
things? How would you organize such UIHandler?

Thanks again.

- Tom

On Thu, 2010-11-11 at 11:39 -0500, Sir Robert Burbridge wrote:
> scribes wha

[Sir Robert Burbridge]

On Thu, Nov 11, 2010 at 11:59 AM, Tom <tomm...@gmail.com> wrote:

Hi Robert,

Thanks for your help. I realize that what I have at this moment makes no
sense at all, which is why I posted.

Anyway, your feedback really helps. However, while I do understand the
purpose of a role in your specific twitter example, I cannot see how
this can be used in many cases. Why would this replace multi
inheritance?

Let's say you have a page with several different UI elements you want users to be able to tweet about:

• A side-bar panel that displays rss info
• A notification system that pops up messages
• Normal page images
• Article comments (from users)

And several elements you don't want users to be able to tweet about:

• Menu items
• A side-bar panel that displays a tag cloud
  
• Normal page audio (streamed mp3 or something)
  
• Article comments from the site admin (such as "article deleted")

Can you think of a good way to add tweeting ability to the inheritance tree?  There are lots of dirty options (mentioned in the prior e-mail).  The only really clean option ends up having a billion classes to disect everything into tiny pieces and do a monumental amount of labor to build anything.  That option is called "Java" (and the plethora of reasonably-well-organized classes is one of the biggest advantages -- and disadvantages -- of Java development).  Perl fixes the problem (beautifully) with MI, and Moose adds roles on top of that, helping to make perl one of the most magical languages around.  But JavaScript isn't perl (even though they're both beautiful, and in similar ways =) and Nickolay doesn't want to go the path of MI -- understandably.  Roles are sufficient anyway.

With roles, you can make a terse inheritance tree that contains only the nodes you need and apply the tweetable role only where needed.  To get you started, you can think of Roles as "enhanced Interfaces" -- instead of just requiring methods and properties (as interfaces do), roles provide some of them and require others.
 

For example, I have a general UIHandler class. This handles the main
interface. It'd have to do a lot of things, which would create huge
functions. This is why I put the PageStructure etc. in a Role. This is
not the purpose of a Role though. So, how should I do these kind of
things? How would you organize such UIHandler?

The statement "it'd have to do a lot of things" is a sign that something's wrong. 

Here is orthodoxy in programming:

1. A function maps input to output (with input X, I always get result Y).
   
2. Every function should do only one thing. (i.e. Atomicity of code)
   
3. Two functions should never do the same thing (i.e. DRY:  DON'T REPEAT YOURSELF!)
   

And here is the corresponding orthopraxy:

1. Start writing your code procedurally
2. When you find you are repeatedly creating the same procedures, move the repeated code into a function.
3. When you find you are repeatedly creating the same functions, move the repeated function to a module.

If your header comments say, "This function takes inputs X and does A, B, and C." then you need three different functions.  You can make a wrapper function for common groupings, but your function should NOT do all three itself:

function do_ABC (X) {
   var z = do_A(X);
   z = do_B(z);
   z = do_C(z);
   return z;
}

function do_A (X) { /* ... */ return X }
function do_B (X) { /* ... */ return X }
function do_C (X) { /* ... */ return X }

The same is generally true of classes:  A single class should do exactly one thing and do it well.  Any related functionality should be relegated to other classes, which the first class utilizes as a property or library.  A UIHandler class should ONLY "handle the UI as a whole" it should not be dealing with pages, buttons, menus, etc. (which are subsets of UI features).

You should be thinking this way:

A UI does ______________ and has _______, _________, and __________.

The "does _______" tells you what methods you should make and the "has _____, ____, and _____" tells you what properties.  Those properties, if they also do thing, should be classes as well.  For example:

A UI does resource management and has resources, pages, a theme, and layouts.

That would mean you should do your class structure this way:

Class("UI",
  has: {
    theme
  , pages:     /* ... An array of Page objects     */
  , layouts:   /* ... An array of Layout objects   */
  , resources: /* ... An array of Resource objects */
  }

, methods: {
    load_resource:   function (resource) { /* ... */ }
  , unload_resource: function (resource) { /* ... */ } 
  }
}

// A "Theme" defines a look and feel (via css) and has rules.
Class("Theme", ... );

// A "Page" represents a single piece of content and has a nav menu, an article, and comments.
Class("Page", ... );

// A "Layout" manages content positioning and has displayable elements.
Class("Layout", ... );

Hope that helps.

-Sir

Thanks again.

- Tom

On Thu, 2010-11-11 at 11:39 -0500, Sir Robert Burbridge wrote:
> scribes wha

--

[Tom]

Hi Robert,

That's great feedback once again. Thanks.

Only comment I have regarding the UI class you created, it does have the
named properties, however there has to be a place where you initiate the
creation of pages and handle the interface logic. For example, you have
to set what page loads first, and you have to make something happen when
a button is clicked.

Especially the "setting what page loads first" seems like a job for the
UIHandler, right?

- Tom

On Mon, 2010-11-15 at 10:45 -0500, Sir Robert Burbridge wrote:
> On Thu, Nov 11, 2010 at 11:59 AM, Tom <tomm...@gmail.com> wrote:
> Hi Robert,
>
> Thanks for your help. I realize that what I have at this
> moment makes no
> sense at all, which is why I posted.
>
> Anyway, your feedback really helps. However, while I do
> understand the
> purpose of a role in your specific twitter example, I cannot
> see how
> this can be used in many cases. Why would this replace multi
> inheritance?
>
> Let's say you have a page with several different UI elements you want
> users to be able to tweet about:

> * A side-bar panel that displays rss info
> * A notification system that pops up messages
> * Normal page images
> * Article comments (from users)

> And several elements you don't want users to be able to tweet about:

> * Menu items
> * A side-bar panel that displays a tag cloud
> * Normal page audio (streamed mp3 or something)
> * Article comments from the site admin (such as "article

> 1. A function maps input to output (with input X, I always get
> result Y).
> 2. Every function should do only one thing. (i.e. Atomicity of
> code)
> 3. Two functions should never do the same thing (i.e. DRY: DON'T

> REPEAT YOURSELF!)
> And here is the corresponding orthopraxy:

> 1. Start writing your code procedurally
> 2. When you find you are repeatedly creating the same procedures,

> move the repeated code into a function.

> 3. When you find you are repeatedly creating the same functions,

> +unsub...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/joose-js?hl=en.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Joose" group.
> To post to this group, send email to joos...@googlegroups.com.
> To unsubscribe from this group, send email to joose-js

> +unsub...@googlegroups.com.

[Daniel Brockman]

[Sorry if this gets duplicated --- I sent it from the wrong address before.]

Sir,

I just wanted to say that this message is one of the most eloquent and
illuminating texts on inheritance, roles, composition, and design in
general that I have ever read.

Have you written any books? Do you have a blog? Twitter?

Thank you,

--
Daniel Brockman, partner & developer
Go Interactive <http://gointeractive.se>
Twitter: http://twitter.com/dbrock
Telephone: +46706880739

[Daniel Brockman]

Sir,

I just wanted to say that this message is one of the most eloquent and illuminating texts on inheritance, roles, composition, and design in general that I have ever read.

Have you written any books? Do you have a blog? Twitter?

Thank you,

-- 

Daniel Brockman, partner & developer

Go Interactive <http://gointeractive.se>

Twitter: http://twitter.com/dbrock

Telephone: +46706880739

[Sir Robert Burbridge]

Thanks, Daniel; I appreciate the kind words.

I don't have any published books, but I am working on a writing project right now that I hope will take me down that road.  Progress is sometimes slow with a job and three kids 4 and under!

I've been thinking for a while now about maintaining a blog.  With the enormous number of blogs out there (of highly varying quality), I've really been hesitant about creating a new one, not sure whether it would add any value.  Lately a few people have been encouraging me to give it a go, and I think your enthusiastic response will tip me over and I'll go ahead and set one up today -- I'll let you know when I do.

One thing that would be helpful would be a list (however short) of topics of interest; that's always the dilemma -- what to write about?  I like lists like this because people prompt with specific questions.  If you have any suggestions for topics that I could start with, or else a reasonable scheme for finding them, I'd greatly appreciate your input!  Perhaps I'll start with the previous e-mail itself and re-work it into a short article.

Thanks again,

-Sir

P.S.  I have a twitter account as SirRobert_B.  I'm not sure active on it, but getting more so =)  I don't really care about tweeting about what I had for breakfast; I like ideas a bit more.

[Sir Robert Burbridge]

Sorry, Tom; I missed your question when I read the e-mail before.

Let's look at the specific points you asked about in the context of the UI class I wrote up before:

• Initiate page creation
  
• Determine which page loads first
• Make something happens when a button is clicked
  

Regarding the question of initiating page creation, if you mean starting things when the page loads, please see the discussion below in the section called "Initiating action."

If, however, you mean a method for creating pages, that's very reasonable; that would definitely count as managing the UI's resources (pages are a UI resource).  Just define a method called something like add_page() that adds a page (and a correspnding remove_page() to remove them).  Then when you need to create a new page, just do UI.add_page({/* ... params ... */}).  I've added the method below in bold.  For kicks I threw in an elegant approach to an extensible event API =)  I use this and it's nice.

Disclaimer:  this code is off-the-cuff, completely untested, and incomplete.  Do not taunt Happy Fun Ball.

Class("UI",
  use: ["Page", "EventHandler"]

, has: {
    theme
  , pages:     /* ... An array of Page objects     */
  , layouts:   /* ... An array of Layout objects   */

  , resources: /* ... An array of Resource objects */

  , events:    /* ... An EventHandler object ... */

  }

, methods: {
    load_resource:   function (resource) { /* ... */ }

  , unload_resource: function (resource) { /* ... */ }

  // Manage pages
  , add_page: function (params) {
      // munge params here if you like...

      // Create a new page.
      var page = new Page(params)
     
      // Add it to the list
      this.pages.push(page)

      // Run any user-defined hooks for adding a page with
      // a hashref of values that should be passed in as
      // event function arguments.  Presumably the "page"
      // property here will be added to some event object's
      // "data" property before the whole object is passed
      // into the event handler.
      this.events.trigger("add page", {page: page})
    }
  , remove_page: function (page) {
        // Remove this page from the array
        this.pages.splice(/* ... */)

        // Call the remove page hooks.
        this.events.trigger("remove page", {page: page})
    }

  }
}

// A "Theme" defines a look and feel (via css) and has rules.
Class("Theme", ... );

// A "Page" represents a single piece of content and has a nav menu, an article, and comments.
Class("Page", ... );

// A "Layout" manages content positioning and has displayable elements.
Class("Layout", ... );

As for the "make something happen when a button is clicked", that's not the class's concern.  The "add page" button is not part of the UI being created, it's part of the UI being used by the user in the page creation software.  So it's your job to tie that in within the page's execution context.  For example:

// I'm just assuming jQuery here because I like it and
// it's got a brief syntax =)
;(function ($) {

  $(document).ready(function () {

    // Create our "ui" and "buttons" variables.  Notice that these are
    // *effectively* global variables, as far as the following code is
    // concerned, but they are really contained within the enclosure
    // provided by the wrapping function's scope.
    var ui, buttons

    var buttons = {
      "create-ui":    $("#create-ui")
    , "create-page":  $("#create-page")
    }

    // A reusable function that can be bound to and unbound from any
    // page event you like.  It always assigns a new UI to the "global"
    // (but hidden) ui variable.
    function _create_ui () {
      ui = new UI()
      // When you create a UI, disable the "create UI" button.
      buttons["create-ui"].click(function () {/* some kind of error */})
      // .. and scope the "create page" button to the context of this ui.
      buttons["create-page"].click(function () {ui.add_page()})
    }

    // Active the "create ui" button.
    buttons["create-ui"].click(_create_ui)
  } 

})(jQuery)

Initiating action

Yeah, there does have to be a place where you initiate the creation of pages and handle the interface logic -- but that place isn't your class definition.  Your classes should be considered libraries; they should be resources that execution code can call to accomplish specific tasks.  They, themselves, should be agnostic to their environments.  That means that a good UI class (for example) should not care whether it's being called from a web page/browser or a server-side testing framework or an emulator of some kind.  It just does what it's told.  Another way of putting it is that all of a class's (or "module's") dependencies should be explicit.  That means that if your class does $("#foo") somewhere, it should have explicitly required jQuery, or if it does document.body... it should have explicitly required that it be in a browser context (or, better yet, it should simply require the features of the "document" variable that it's actually using, so that a browser emulator would also be able to call it).

That said, the class should never be the "prime mover" of the application.  It should not be the source of the origination of action in the application.  With the statements about what a class "does" and "has" that I made previously, I hinted that the nature of a class or module is simply to manage and correlate inputs and outputs.  That means that a class, for example, should be able to be instantiated, and should perform it's methods.  Executing the class's definition should have no effect whatsoever beyond mere definition.

That means that your actual page should have to make everything run.  The good news is that that can be very tiny.  For example:

/**
 * init.js
 * Gets things going on the page.
 */
;(function () {
  // Create an instance of the UI class and call the "run" method.
  new UI({"document": document, "window": window})
    .configure(/* ... */)
    .run()
})

That's a legitimate way to run things. 

-Sir

P.S.  For whatever it's worth, if you're interested in the broader concepts underlying these paradigms, the approach to philosophy that says, "I don't care what it is, I just care if the interfaces match up" is Phenomenology.  Modern "metaprogramming" is largely phenomenological.  Read about that if you're interested in the underlying philosophical concepts (esp. Heidegger).  But don't forget that it's a utilitarian philosophy and doesn't lay claim to Truth, as such. =)  The classical "Object Oriented Programming" philosophy is the Platonic philosophy of Forms.

To unsubscribe from this group, send email to joose-js+u...@googlegroups.com.

[Tom]

Hi Robert,

That's great feedback again. Thanks.

I do understand your point that everything should be considered a
library. I had followed this philosophy for the individual elements, the
UIHandler for me was more like a handler that'd put all these individual
elements together (I only have 1 page).

I can see why this would be inappropriate. You initiate your interface
in init.js. I have to say though that your example seems to be quite a
basic situation. For example, if I want to create specific pages that
have different actions when certain events happen, I would have to
create a handler for this, right? This is what I originally meant to do
in UIHandler.

Thanks again.

- Tom

On Wed, 2010-11-17 at 15:16 -0500, Sir Robert Burbridge wrote:
> Sorry, Tom; I missed your question when I read the e-mail before.
>
> Let's look at the specific points you asked about in the context of
> the UI class I wrote up before:

> * Initiate page creation
> * Determine which page loads first
> * Make something happens when a button is clicked

[Sir Robert Burbridge]

Hey Tom,

Why don't you write up a brief use case so I can get a better feel for what you have in mind?  Real examples are always easier than me trying to make something up that matches your project (sorry; I should have asked sooner! =)

If you can give me short description that explains a subset of the trickier examples (that I missed), I'd be more than happy to work it out with you.

-Sir

To unsubscribe from this group, send email to joose-js+u...@googlegroups.com.

[Tom]

Hi Sir Robert,

If you really enjoy writing, I can recommend you the following topics:

- How to convince investors of an idea without giving your idea away
- How to get in contact with investors for a project
- How to deal with international contracts and law when selling projects
- When one should decide to create a company rather than work as an
individual
- The pros/cons of working as an individual
- How to take culture differences of international target markets into
account
- How to create international business or product names appealing to
international targets
- How to create a working user-driven system where input is made by a
part of the people interested in the output
- How to market a project with low liquidity available
- How to market a project with average liquidity available
- comparison of IDEs for linux for client and server sided Javascript
- proper understanding of OOP concepts
- need for multi inheritance or role alternatives
- How to separate visuals from app logic
- How to setup a high availability cloud based infrastructure where load
is balanced, and if balanced visitors are appointed to the nearest
servers available (GeoDNS or other alternatives, some will not be
possible with a cloud service - why?)

These are in no order. Obviously one cannot be an expert in all these
fields, but they are what interests me -- so you might get some
inspiration.

Good luck.

Regards,
Tom

> +unsub...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/joose-js?hl=en.
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Joose" group.
> To post to this group, send email to joos...@googlegroups.com.
> To unsubscribe from this group, send email to joose-js

> +unsub...@googlegroups.com.

[Sir Robert Burbridge]

Thanks =)

-Sir

To unsubscribe from this group, send email to joose-js+u...@googlegroups.com.

[Tom]

Hi Sir Robert,

Sorry for the late reply. I will try to create a good example as soon as
I can, but this might take a while.

Thanks.

- Tom

> To unsubscribe from this group, send email to joose-js

[Sir Robert Burbridge]

Tom,

No worries.  It doesn't have to be a full example, just a blurb that we can use as a spec.  For example, "I want to create a page that has six buttons:  'create-layout', 'create-page' ... and when you click this button that happens.  The real issue is that I just don't understand what you're trying to accomplish =)  If you've even got a graphical UI mockup, we could work with that.

Take your time; let me know =)

-Sir

To unsubscribe from this group, send email to joose-js+u...@googlegroups.com.