Dan Steinman wrote:
>As I have it now there is no way to call an event because the loader itself can load
>the event objects, and is meant to be included before any other files. I could add a
>subobject (if event.js is included manually) to call such events. I agree this is is
>a good idea so I will keep it in mind.
>
>As Robert mentioned, you can't call DynAPI.library.load() inside the file, the
>dependencies must be assigned before you load the file. The dependency list for all
>the files within DynAPI will already be there. But for your own objects, you'll need
>to include that code in your page (or in a js file that is loaded through the
>libloader beforehand).
>
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.
>....
>- updated library add() and addPackage() syntax will be:
> dynapi.library.add(objectName,objectSrc,dependedObjects,packageName);
>
What if a widget requires more than one object?
>- 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.
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.
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.
--
Michael Pemberton
[EMAIL PROTECTED]
ICQ: 12107010
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://www.mail-archive.com/[email protected]/
