
Hello all,
I am trying to port our echo2 application to echo3. the package name replace was easy. The main problem I am having is because of Echopointng components.
In our echo2-based application we used the echopointng components everywhere like Tree, DefaultMutableTreeNode,JavaScripteval etc.
Now as far as I know there is no ported version of echopointng in svc or in echo3go available. is the Porting of Echopointng in progress? can i get already ported components from cvs?
Or should I start converting components back to basic Echo3 ....
Please advice. thanks a lot in advance.
aze
There is a Tree in Echo3 Extras now.
For JavaScript Eval, I'd recommend writing a command. No docs for writing these yet in Echo3, but you'd be in decent shape if you studied / cut-and-pasted from the Echo3 source of the BrowserOpenWindowCommand stuff. (There's a Command object, CommandPeer, client-side JS object, and entry in the SynchronizePeerBindings.properties file.)
As I understand it there will be an EchoPoint 3, but I do not know the status.
epng3 port is just beginning. I'll send out a full announcement soon.
Hi,
great,
are you planning to port all components of epng to epng3 ? what do you think how long could it take?
Aze,
Great to hear that EchopontNG is being ported. We have a very large
Echo2 application that makes extensive use of EPNG and which we want to port to 3.0. We'd be happy to give some help especially in testing etc.
Edge
Great, can't wait for it... ;)
Anyway, I wonder if the policy of duplicated widgets (Label/LabelEx, Button/ButtonEx) will be continued in version 3. In my opinion now would be a good moment to actually merge them, because for the end user there is no case having the components duplicated.
I'm aware that the reasons therefor were on the developer side (reducing the to risk for breaking the base implementation, less ppl need granted SVN commit access to the core), but with a good coordination effort, shouldn't it be possbile to overcome these issues?
cheers, Chris
Great hearing that! Thanks for all the work.
For us, we don't have any problem having the duplicate classes (e.g Label, LabelEx) but if it could be merged, the better. I'm just afraid that by porting with the merge and by refactoring each usage of the old EchopoingNG classes, it could origin a lot of problems...
See Announcement: [url=http://forum.nextapp.com/forum]http://forum.nextapp.com/forum]