> Can you explain why you are using async loading of files? This seems to
> be the main reason for not being able to specify the required objects in
> the code being loaded
I wasn't able to properly get synchronous loading working in the first place, but I
don't believe that asynch loading is much more difficult to work with. I have load
handlers which are called when a script, or several scripts are finished loading, or
are already loaded. After some further thinking I think we'll be able to get
dependencies to be defined in the files anyway - as long as some coding guidelines are
followed precicely. I haven't tried it yet but such a guideline would go like this:
- in the script file include a callback which sets it's dependencies:
dynapi.library.setDepencency('MyObj','DepObj');
- create the constructor as usual:
function MyObj() {
this.DepObj = DepObj;
this.DepObj();
}
- I have a new function to wrap the prototype assignment:
MyObj.setPrototype('MyObj','DepObj');
- In the main() function, define the rest of the methods, or scrap the above command,
and do a manual prototype assignment here also:
function main() {
MyObj.prototype.myMethod = function() {};
}
- Include a check to call main() if the script is included manually (not through the
lib loader)
if (!dynapi.loaded) main();
> >- updated library add() and addPackage() syntax will be:
> > dynapi.library.add(objectName,objectSrc,dependedObjects,packageName);
> >
> What if a widget requires more than one object?
You can add an array of objects, or dependencies also:
dynapi.add(['MyObj1','MyObj2'],'src.js',['Dep1','Dep2']);
> >- I've got a class/inherit system pretty much down. Instead of doing the following
>inside widget constructors::
> >
> > this.DynLayer = DynLayer;
> > this.DynLayer();
> >
> > you can now do:
> >
> > this.inherit('ThisObject','ParentObject', argument1, argument2.... argument8);
> >
> Looks interesting...
>
> I know I seem to be spending too much time bitching, I just find it hard
> to understand why all this time and effort has been put into making a
> system that is causing features to become unable to be implemeneted and
> also create additional overhead.
Which features are not able to be implemented? Everything so far is working great.
I've actually changed that syntax a bit and made "this.inherit()" completely optional.
Instead you do the following:
function MyObj(arg1) {
this.inherit('ParentObj',arg1); // optional, does the same as:
// this.ParentObj = ParentObj;
// this.ParentObj();
}
dynapi.setPrototype('MyObj','ParentObj');
setPrototype is merely a wrapper around the MyObj.prototype = new ParentObj command,
and it also adds the following prototypes:
MyObj.prototype._className = 'MyObj';
MyObj.prototype._pClassName = 'ParentObj';
MyObj.toString = function() {return '[MyObj]'};
The class names are useful, allowing you to keep track of what the proper constructor
function is, and what objects it inherited from. I don't believe the
dynapi.setPrototype() function adds any overhead since it's only called once and is
only a wrapper to very simple commands.
> Especially since they are being spoken about at the same time as
> changing "DynAPI" to "dynapi". It seems that the theory of
> simplification is being overlooked in the process of building a utopian
> loader that has already been started and is too far down the track to be
> changed. It also looks like we are almost falling back into the old
> trap of the structure changing faster than we can adjust our code.
This library loader is both easier to work with and more powerful, and is not
manditory. You could still use the package include with minimal changes, but I highly
doubt you'd want to. You can also include the script tags manually and have no
library loader at all.
> Too many changes are being implemented without any consultation. It is
> getting to the point where we need to see some of the code before we
> should be forced into making these changes. Just as we did with the
> DynAPIX phase, I see little reason why we should not have access to the
> code that you are basing your work on. It is a little hard to make
> comments / give feedback on a structure / syntax sight unseen.
>
> I apologise if these comments sound a bit extreme, but as I we have
> already gone through the process of structure redesign as various
> points, I don't really see why this one should be done from such a
> removed position. It is as if you are saying that we are not going to
> be able to comprehend your new work unless we have our hand held. If it
> is simply a risk of being overwhelmed with questions, I am not sure that
> this is the best way to go about it.
I think it's better to have a codebase that is fully working before letting others
critique it. You can critique the syntax (and how it will be used) though, that's why
I was making note of them.
Cheers,
Dan Steinman
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://www.mail-archive.com/dynapi-dev@lists.sourceforge.net/
