Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Framework Issues  (Read 25411 times)
Rhysyngsun
Courseware Beta
Sr. Member
***
Posts: 51

Nathan Levesque

 - rhysyngsun@gmail.com  - rhysyngsun
View Profile WWW Email
« on: January 08, 2008, 06:58:11 »

I've been wrestling with some issues that have impeded me from releasing the initial version of the framework. I'm hoping someone has some experience that can shed some light on this:

The problem revolves around how Python's import operation works at runtime. I initially followed this methodology (for example):

from org.puremc.python.core.view import View

which imported the View class from the org.puremc.python.core.view module.

This method of importing works fine, until the import becomes cyclical. Meaning module A imports module B. Later down the line B imports A. this works fine in compiled languages, but in Python, the interpreter has yet to finish interpreting A because it has not finished with B.

After some research, it appears the best methodology is to just use a standard import and import the entire module. This solves the import problem, however now the classes need to be referenced by the entire package name and certain modules can't be found:

class MacroCommand( org.puremvc.python.patterns.observer.Notifier, org.puremvc.python.interfaces.ICommand, org.puremvc.python.interfaces.INotifier ):
AttributeError: 'module' object has no attribute 'observer'

The Python documentation is sparse at best at how import functions. I know there was a previous problem with cyclical import with the standard import, but it appears that "from _module_name_ import cls" was never checked or fixed.

This is a major roadblock and as far as I can see the only one at the moment.

The only immediate solution I know of is to break down the package structure and just have everything reside at a root level, possibly in a single file. I really don't like this solution as it breaks standards and file structure with the other PureMVC implementations.

I've attached the framework code as it is now (standard import implemented atm), but it's untested due to this import issue and I don't want to think of committing it to the repository until that is done.
Logged

puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: January 09, 2008, 07:21:53 »

Sounds pretty bad. I definitely think keeping the structure intact would be best. All in one file sounds pretty icky.

I don't know anything about python. I will later copy this post to the public Platforms forum, as I'm not sure anyone else has access to this one yet.

-=Cliff>
Logged
Joel Hooks
Courseware Beta
Sr. Member
***
Posts: 146


baby steps

 - 46288188  - passport@provinsal.com  - joeltuff
View Profile WWW Email
« Reply #2 on: February 11, 2008, 08:09:51 »

So what happened with this? Defeated? :<
Logged

http://joelhooks.com - my ramblings about developing with actionscript and python using pureMVC and django respectively.
Rhysyngsun
Courseware Beta
Sr. Member
***
Posts: 51

Nathan Levesque

 - rhysyngsun@gmail.com  - rhysyngsun
View Profile WWW Email
« Reply #3 on: February 12, 2008, 09:24:52 »

I'm still working on it, hopefully I should be arriving at a conclusion one way or another in the next week or so.
Logged

tobydeh
Moderator
Sr. Member
*****
Posts: 52


View Profile Email
« Reply #4 on: March 09, 2008, 12:29:01 »

This problem was pretty easy to fix.

Using "from x import y" is correct, you should not import the whole module. Just avoid circular imports, they usually indicate bad design / structure anyway.
Logged
tobydeh
Moderator
Sr. Member
*****
Posts: 52


View Profile Email
« Reply #5 on: March 10, 2008, 02:36:37 »

I have the Python port in a working state, i will upload asap.
Logged
Rhysyngsun
Courseware Beta
Sr. Member
***
Posts: 51

Nathan Levesque

 - rhysyngsun@gmail.com  - rhysyngsun
View Profile WWW Email
« Reply #6 on: March 10, 2008, 10:19:46 »

I have the Python port in a working state, i will upload asap.

Sounds good, I look forward to seeing it. Thanks a bunch :-)
Logged

tobydeh
Moderator
Sr. Member
*****
Posts: 52


View Profile Email
« Reply #7 on: March 10, 2008, 04:02:26 »

There is a circular import in the facade / notification area which unfortunately cannot be avoided.

The python port cannot simply be a modified version of the code, it needs to be completely re-designed into a python structure.

I will have a look at some options and see if i can find a new solution for the python port.
« Last Edit: March 10, 2008, 05:04:34 by tobydeh » Logged
Rhysyngsun
Courseware Beta
Sr. Member
***
Posts: 51

Nathan Levesque

 - rhysyngsun@gmail.com  - rhysyngsun
View Profile WWW Email
« Reply #8 on: March 10, 2008, 06:21:50 »

There is a circular import in the facade / notification area which unfortunately cannot be avoided.

The python port cannot simply be a modified version of the code, it needs to be completely re-designed into a python structure.

I will have a look at some options and see if i can find a new solution for the python port.

Yes, I believe that's where I had run into the problem before. I have read that using plain import can handle circular imports, but if I recall correctly, this raised other issues.

I guess that's my C language background working against me.

Hopefully we can find a workaround.
Logged

tobydeh
Moderator
Sr. Member
*****
Posts: 52


View Profile Email
« Reply #9 on: March 11, 2008, 01:16:46 »

As opposed to just modifying the code we need to build from new perspective, avoiding the circular imports.

In puremvc everything knows of the facade and vice versa! How can we provide the same functionaltiy in python? ???
Logged
tobydeh
Moderator
Sr. Member
*****
Posts: 52


View Profile Email
« Reply #10 on: March 11, 2008, 04:45:32 »

I have found a way to create the application wide Facade Singleton as well as the Model, View and Controller Singletons.

I am going to draw up the new package structure asap, when this is completed i can begin a new Python port.
« Last Edit: March 11, 2008, 04:53:43 by tobydeh » Logged
Rhysyngsun
Courseware Beta
Sr. Member
***
Posts: 51

Nathan Levesque

 - rhysyngsun@gmail.com  - rhysyngsun
View Profile WWW Email
« Reply #11 on: March 12, 2008, 06:03:01 »

Sounds good, I have source code updated to version 2, I'll upload it later so you don't have to spend time rewriting all the functions.
Logged

tobydeh
Moderator
Sr. Member
*****
Posts: 52


View Profile Email
« Reply #12 on: March 12, 2008, 06:08:54 »

I have re-written from scratch in conjunction with v 2.0.1

It is only a basic working package and a lot needs to be improved upon...

Run "main.py" to see some tests.

some issues:

At the moment  the facade class must always be imported using:

import *
NOT
from * import *

this means any references to constants in the AppFacade class must include the full package path which is annoying.

Also the Facade.getInstance and AppFacade.getInstance point to different locations in memory, does this matter? I was trying to think where this may break the application.

Let me know your thoughts.


[attachment deleted by admin]
« Last Edit: March 12, 2008, 06:21:23 by tobydeh » Logged
Rhysyngsun
Courseware Beta
Sr. Member
***
Posts: 51

Nathan Levesque

 - rhysyngsun@gmail.com  - rhysyngsun
View Profile WWW Email
« Reply #13 on: March 12, 2008, 06:41:37 »

I have re-written from scratch in conjunction with v 2.0.1

some issues:

At the moment  the facade class must always be imported using:

import *
NOT
from * import *

this means any references to constants in the AppFacade class must include the full package path which is annoying.

Best solution would be to use import as to define a local name for the module:

:
import com.dehavilland.test.app as app
then later:

:
app.AppFacade.TEST3


Also the Facade.getInstance and AppFacade.getInstance point to different locations in memory, does this matter? I was trying to think where this may break the application.


Not quite sure, but the best thing to do next would be to rewrite the unit tests (of course taking into account the differences in implementation). If the unit tests run fine then I believe we can commit the code to the repository and begin coding apps!

Thanks Toby, glad to have a strong Python programmer on the team!
Logged

tobydeh
Moderator
Sr. Member
*****
Posts: 52


View Profile Email
« Reply #14 on: March 12, 2008, 06:45:23 »

Thanks for your comments Nathan.

I thought about using "as" But i generally try to stay clear as it can cause headaches when debugging, but having said that it may be the best solution.

I have already started the unit tests, ill upload a new zip when they are done.

** UPDATE **

All unit tests for "core" package classes re-written and passed
Now working on "pattern" package classes
« Last Edit: March 12, 2008, 10:20:03 by tobydeh » Logged
Pages: [1]
Print