What to do with OXD-mForms-2.0

[Brent Atkinson]

Greetings,

A little while ago, I asked for input on a modified midlet - one with dynamic expression support. That midlet was generated from a fork I have been maintaining on github. Originally, I was just using git-svn locally, but for a number of reasons I needed to make it public and remote. Eventually, I would like to reintegrate, but I'm comfortable merging until people are comfortable.

https://github.com/batkinson/OXD-mForms-2.0

I invite you to take a peek at it. There are some notable changes in addition to the protocol support;

 * the project has been mavenized
 * scrubbed of epihandy-isms
 * the old "modules" were merged into a single project except where a division was clean and had real value, like the model objects
 * include a number of useful unit tests, especially for the newer code

One reason I was holding off was that I was that I needed to figure out how debugging and IDE integration were going to work and the tooling needed to be tweaked to work with Java ME projects. In the end, I ended up patching the required tools, submitting the patches back to the respective projects and deploying patched versions for us to use until the patches are included in the projects - or we can continue to use ours. I patched two maven plugins: the maven eclipse plugin to enable completely overriding the classpath containers, and the pyx4me plugin to enable debug mode when running j2me:run.

The end result is that we have a complete working J2ME maven setup that works much like the server project. It is much more portable and will build on initial checkout without the WTK. It also allows us to use SNAPSHOT versions and simplifies releasing and dependencies considerably.

Feel free to give it a spin. If you like it, perhaps we can try to work it in soon. I would love to hear your feedback.

Brent

[Shashank Garg]

Hi Brent,

This is great. We will give it a spin at Handsrel. Support for dynamic expressions makes it extremely interesting and not having to depend on WTK is an additional bonus. This will give additional life to projects where low-cost J2ME enabled phones are the only option.

Am I correct in assuming that if an XForms based form is developed by hand it should work on this midlet? Or, that we could also use your other project, the Pivot-based designer prototype, to design forms for this midlet?

Thanks,
Shashank

Brent

--
You received this message because you are subscribed to the Google Groups "openXdata Developers" group.
To post to this group, send email to openxd...@googlegroups.com.
To unsubscribe from this group, send email to openxdata-de...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/openxdata-dev?hl=en.

[Brent Atkinson]

Hi Shashank,

You are correct in your assumption in that you will have to modify the form definitions manually to use the extended support (but it should still be backwards compatible with old form definitions). Because they both rely on the Condition class, neither designer can fully utilize the extended support. It should be a simple matter to open up the fields as computations, but it will mostly be a question of what a typical user can cope with.

Brent

[Mark Gerard]

+1 on mavenising. 

Mark

[Dagmar Timler]

Hi

Sorry for the late response. I was looking at doing the ticket #633 in this iteration.

The path forward seems to be obvious according to our new process: Create a patch. Without a patch it is not possible for the code to be reviewed properly. 

Unfortunately it seems that a lot of changes were made in this branch, and I think that as far as possible they should be broken down (and tickets created for each). E.g:

• Remove epihandy-isms
• Mavenize the project + change modules
• Unit tests for existing code
• Dynamic Expressions (and unit tests for new code)

I am happy to look at the code at github. I think this really needs to be done sooner rather than later to avoid loss of code in the trunk (there are a couple largish changes recently).

Thanks

Dagmar

[Brent Atkinson]

Unfortunately, patches won't work well for the types of operations
needed, like renaming with history. Also, the changes for evaluation
support are mostly outside of the code base (an evaluator engine, and
xpath compiler). The only place where they come into contact with the
original code is that Condition is replaced in the SkipRule and
ValidationRule classes and now just contain compiled expressions (and
evaluate using the evaluator when firing) instead.

I wonder if it may work more smoothly to integrate the latest changes
from Subversion into the fork. People can evaluate it and decide
whether it's worth going with. If it's deemed acceptable, it should be
a matter of an svn dcommit.

People can easily take a peek at the fully history of changes, and the
operations needed should be abundantly clear from the change logs. I
did my best to make minimal and well-scoped changes and commit
messages are descriptive - so it shouldn't be too taxing. For the most
part, the main portion of the code is untouched aside from renaming
and removing Epihandy-isms.

As for tests, the code I wrote was developed with fair test coverage.
I also added regression tests for a number of issues I merged in from
trunk and the tests run as part of the build (so they actually are
utilized). At this point, with the exception of integrating the latest
changes, the project health should be better for the fork than in
trunk.

Thoughts?

Brent

On Jan 19, 9:30 am, Dagmar Timler <diggityd...@gmail.com> wrote:
> Hi
>
> Sorry for the late response. I was looking at doing the ticket #633 in this
> iteration.
>
> The path forward seems to be obvious according to our new process: Create a
> patch. Without a patch it is not possible for the code to be reviewed
> properly.
>
> Unfortunately it seems that a lot of changes were made in this branch, and
> I think that as far as possible they should be broken down (and tickets
> created for each). E.g:
>

>    - Remove epihandy-isms
>    - Mavenize the project + change modules
>    - Unit tests for existing code
>    - Dynamic Expressions (and unit tests for new code)

[Sarah Bird]

Hi,

I can't speak to the technical wiseness of anything, but I'm happy to test a new version of the mavenized fork and compare to current mforms.

Best,

Bird

[Dagmar]

Welcome back Brent!

[Brent Atkinson]

Thank you :D

[Brent Atkinson]

Greetings,

I'm continuing this thread since the question is still open. I took ticket #633 last development iteration and wasn't able to get enough time to make much progress on it. However, late last week I was able to bring my fork up to date with J2ME/trunk in svn. All pertinent changes were integrated.

The next steps to take are not predetermined, but the following is what I was thinking:

* Devs try out the project by building it.
* ...try running it, and hooking a debugger up to it (it's different/simpler now, and I can give instructions).
* ...try installing the protocol jar in an existing server installation and download/upload studies/forms/data.

The things people should be especially critical of:

* Major pieces of functionality missing
* Problems with the new paradigm that may impede or halt ongoing work in a major way

We should be looking for fundamental issues that will be deal-breakers for the approach in general. Minor issues or regressions are easily handled as a normal part of our development process and should not prevent taking the leap forward. The changes will bring openxdata projects into a better overall alignment, improve project health, simplify the release process, while enabling a more functional mobile client and laying the foundation for solutions to a large number of long-standing feature requests. Our decision to move forward with it (or not) should take this into account. 

If people are relatively comfortable with the approach, we can:

* make the upcoming mForms milestone mforms-2.0
* merge the changes back into trunk and continue our processes
* change the build server configuration for mforms to be a maven build (hooray for easy releasing and branching!)
* update the documentation for how to setup/run/debug/release the new project

If people are ok with this approach, I can start pulling together the pertinent information and can send it out as soon as we're serious.

Thanks,

Brent

[Jørn Ivar Klungsøyr]

Hi,

 

This sounds like a good approach!

 

If relevant, you could also send a zip with mforms jar/jad + protocol jar, then I can also add a separate instance to a demo server so it is easier to verify for non devs.

 

Best

Jørn

 

____________________________________________________________________________
Jorn Klungsoyr
openXdata - Centre for International Health, University of Bergen, Norway
www.openxdata.org / www.cih.uib.no / www.openrosa.org / www.open-mobile.org
Mobile: +4791365731, Skype/GoogleTalk: jornklung Alternative email: jorn.kl...@gmail.com
Post: Postboks 7800, 5020 Bergen, Visit: Årstadveien 21, 5th Floor, Bergen
                       ------¤¤¤¤------

[Shashank Garg]

Brent,

I think you should go ahead and this should transition into mForms-2.0. What is the major functionality missing?

Shashank

[Brent Atkinson]

Hi Jørn,

I intentionally did not ask for user feedback or testing. Frankly, it's not helpful at this stage and just confuses things. This fell flat once already because of a similar confusion. I'd like to avoid going through that again, if possible.

This is first and foremost a technical advance and users are unlikely to be interested or informed enough to say much about it. To make it explicit, the question being asked is: developers can you give any reason why this won't work going forward, and if so, why? Until we answer that, we shouldn't be moving on.

Brent

[Brent Atkinson]

Shashank,

Thanks for your feedback. I'm of a similar opinion, but I'm not interested if people don't really support them and look at them as improvements.

To answer your question, there shouldn't be any major pieces missing. I'm really just asking for some help and extra pairs of eyes. Sarah helped to identify some defects relating to the mismatch between the form data access routines and the way repeats were handled, but on the functionality is mostly intact.

The real problem is that the original code is rife with kludges and they are tightly coupled to kludges in the Condition class. The evaluation engine is very simple and general-purpose, but the interfaces to the rest of the code aren't as general purpose. When we could case-code around that, things worked, but there is a mismatch we will need to rectify shortly after moving forward (if we do).

I hope that helps,

Brent

[Shashank Garg]

Brent,

I certainly see the changes as improvements. We are also trying to use this code-base and hoping others will do the same too.

Best,
Shashank

[Dagmar Timler]

Hi Brent

I must confess and say the changes in the branch are rather overwhelming. In the future, it would be better to have tackled the features separately which would also make reviewing a lot easier.

I am happy for you to go ahead and merge the fork into the trunk and then we continue from there. I think it is best to merge as soon as possible.

Alternatively, if you would like a review of the code, please can you provide some high level overview and/or pointers about where to start. Some diffs, of code that should be reviewed, would be handy, and make the process a lot less painful.

Thanks

Dagmar

[Brent Atkinson]

Hi Dagmar,

Thanks for replying. You made this position clear the first time you raised it and I thought we had addressed it, but that's fine if it's not to your satisfaction. I have been maintaining the fork since early August, and it pre-dates the process changes. Also, it wasn't intended to be mechanically merged back, but it was compelling because it was better than trunk in a number of key ways and it was done in a way that it can be backwards compatible with the existing system. The additional functionality was really only feasible with tests and easier dependency inclusion and it would have been a nightmare trying to maintain multiple divergent forks. Worse, it wouldn't necessarily have made the final integration easy when merging the multiple forks. Finally and more importantly, it is only possible because I have been maintaining it... otherwise it wouldn't really be an option.

It's still a choice. I'm fine if people are resistant, I just don't have the time or patience to maintain the fork and everything else, especially if it doesn't have a future.

Brent

[Dagmar Timler]

Hi Brent

I don't think anyone is resistant to the idea of the improvements you made, and I hope that is not how my previous email came across. 

I gave two options of how to move forward - either just merge it so we can move forward and you don't need to maintain your branch any longer (I imagine that is not an insignificant task). Or if you aren't comfortable with that, if you can give me a high level summary/diagram/diffs I can take a look at the code.

I really think the first option is actually the best and most realistic option.

Thanks

Dagmar

[Daniel Kayiwa]

I could be wrong on this but this is what i think could be the source of some small resistance, not to the improvements, but to the process of incorporating them:

1) The existing trunk has been in use and hence more tested than the fork. So people who already have live deployments may be slow to ...
2) Some people could be asking, in future, whenever one creates a fork better than trunk, will things always be done this way?

I think in summary, there needs to be a consistent way of contributing towards the improvements of the existing oxd code base.
In other wards, if one wants to contribute, he or she should be willing to as much possible follow the community agreed upon procedures.

As for the current state of things, the decision lies in the hands of the core devs!!!

If we keep uppermost in our minds the unkind and unjust acts of others, we shall find it impossible to love them as Christ has loved us; but if our thoughts dwell upon the wondrous love and pity of Christ for us, the same spirit will flow out to others.

[Brent Atkinson]

Heh, sorry, it's my pedantic robot-brain. There's a negative connotation to resistant I didn't intend. I was thinking the dictionary version: characterized by or showing resistance; resisting. Anyway, I was asking for people to resist, and I would much rather resolve it now than later. So, I'm sorry if that came out wrong...

Getting back to the issue, I can do both. I'll have to continue maintaining it through the iteration, but option 1 can be fairly simple if we don't take all the history with it. Git-svn doesn't seem to handle merges well from git to svn, but I should be able to easily squash the history to the svn branch and dcommit just fine.

As for the changes, most of the work is self-contained in the compiler and the evaluator. The only major changes to the other code are refactoring and I think I explained that in more detail before. Essentially, other than name changes and module reorganization (though they weren't really *modules*, which is why I did it) there isn't much to evaluate. The evaluation support is the largest functional change to the existing code and that amounted to removing the Condition class and making SkipRule and ValidationRule execute compiled RPN expressions rather than the Conditions.

The protocol needs to also change, but that was just a simple patch to the proto project to change the dependencies to include the model, compiler and code generator, to change the names of the classes changed in the referenced server-support classes. The server-support classes is where the magic happens. When transforming the xform definition from xml to FormDef, the compiler is used to compiler RPN expressions rather than constructing Conditions.

Brent

[Jørn Ivar Klungsøyr]

Hi Brent,

 

My suggestion is to fold this back asap given that there has come no blocking concerns or objections from the active developers of the latest iterations.

 

Also given that mforms / server has branched off for an upcoming public release you will have a number of iterations to fine tune and adjust any potential issues that could come up before mforms 2.x hits the public.

 

Best

Jørn

____________________________________________________________________________
Jorn Klungsoyr
openXdata - Centre for International Health, University of Bergen, Norway
www.openxdata.org / www.cih.uib.no / www.openrosa.org / www.open-mobile.org
Mobile: +4791365731, Skype/GoogleTalk: jornklung Alternative email: jorn.kl...@gmail.com
Post: Postboks 7800, 5020 Bergen, Visit: Årstadveien 21, 5th Floor, Bergen
                       ------¤¤¤¤------

 

From: openxd...@googlegroups.com [mailto:openxd...@googlegroups.com] On Behalf Of Brent Atkinson
Sent: Tuesday, February 21, 2012 12:07 PM
To: openxd...@googlegroups.com
Subject: Re: [openXdata-dev] Re: What to do with OXD-mForms-2.0

 

Heh, sorry, it's my pedantic robot-brain. There's a negative connotation to resistant I didn't intend. I was thinking the dictionary version: characterized by or showing resistance; resisting. Anyway, I was asking for people to resist, and I would much rather resolve it now than later. So, I'm sorry if that came out wrong...

[Brent Atkinson]

Daniel,

1.) That may be, but no one is asking for people to deploy this tomorrow. It's about incorporating it into development and part of the benefit of moving to it is not being locked up like that in the first place. The project actually provides a framework for testing and makes it part of the build process. Testing code once is invalidated once changes are made... that's why we want to automate it, so we can identify it without deploying. The fact is that the fork is testing more than we are on trunk and it has caught problems more than once.

2.) I certainly hope so, or I'll probably end up working on the fork with them! ;D

A major advantage of being open is community contributions. We didn't have the ability to accept them easily from people outside the project before. With some of the process changes, we now have that. We still have some work to do with allowing divergent extension, but much of the work done was to foster more outside participation and turn contributors into developers (with high quality standards). The fork was undertaken before this was established, but even so it still was more of a rewrite/refactor than a typical contribution would be. If people want to do this type of thing, it would work like on any other major open source project - get involved, become developers, branch, and merge if acceptable.

Relating to that, I sense that people have an unhealthy fear of branching. I think this is because they haven't figured out how to harness it effectively and they've seen what happens when people don't manage things well - I've seen that in other places as well. However, as long as the integration burden is on the branch maintainer and not the mainline, it's harmless. If the commits are clean and well-documented, it's easy to see the quality of work. This is exactly what I've done and I've spent hours resolving conflicts to do it. That's not the general state of most of the branches I've seen from our community at this point, so it's appropriate that it would be treated a bit differently. For one, you should be able to build the project and it should work much like the latest trunk works.

Lastly, there is such a lack of tested behavior that changing anything in major ways for the mobile is a significant risk - not just for this, but in general. If not anything else, putting a framework for testing in place and actually using it is important for the longer term project health.

Brent

[Brent Atkinson]

Jørn,

You mean after iteration end though right? I'm ok holding off and taking up the integration burden until then. Also, I don't want to drop-the-bomb without someone trying the build out. I'll send along the protocol patch and jar as well.

Brent

[Jørn Ivar Klungsøyr]

Whether this iteration or next is something I don’t think I have or should have any say in…. :)

If I did have a say, I would say go ahead and reintegrate in this iteration.

[Shashank Garg]

In my opinion, we should go for it.

Shashank

[Brent Atkinson]

Ok,

Well, I'm in agreement that the timing of that integration isn't something appropriate for Jørn to dictate, except for exceptional circumstances. I would like to get some informed feedback, but there isn't a technical reason preventing integration. The only thing we'll have to do is adjust the milestone name, which is a small issue.

Brent

[Donald mteka]

Hi Brent,
 I hooked up you RPN implementation (hence forth referred as simply RPN)  to replace the Condition class.
 I must admit it is extremely powerful, cool and easily extensible!
 I wonder what really is inhibiting the move for RPN because it is a tiny addition that you can be confident it works,
 and replace the Condition class whether the Condition class has been in use and tested for decades!
    But the bonus comes at  easy of extending the expressive power of RPN and is way easier for any maintainer.
 I don't think people should be too comfortable with the current mforms implementation, considering  the rounds you have to make to add a feature or fix something. That's what drove me to revamp it at first place. 
    Even the list of pending feature requests and fixes, is somehow accelerated by current implementation, because when you read the tickets, the concept to implement or fix  comes straight forward , but enter the mforms implementation and you will know that it's easier said than done...
 
  Yesterday, I reviewed the implementation and  merged the RPN in my fork and no, flaws! If for any reason people are afraid to break things, they should learn that the Condition class is mainly used in 3 classes, EpihandyXform,SkipRule and ValidationRule. EpihandyXform uses it to inject conditions in  the SkipRule and ValidationRule classes which control the formdata editing . And merging involves squashing off just few lines of code in either class. It is as easy as that.
  And if you could do so, then follows perhaps the least harmful but crucial changes, as best put by Brent himself:

  * the project has been mavenized
  * scrubbed of epihandy-isms
  * the old "modules" were merged into a single project except where a division was clean and had real value, like the model objects
 

 If you have at least "looked" at the fork, I need say no more.

  So if the devs test the RPN  and discover no flaws(or fix if any), no one will really frown at you for getting rid of the Condition class. It will be left to the devs to pull their hair to lift the form designer to the same height!

Back to the RPN itself, for any dev who has taken time to review it (at least brent has done so!), i have these questions/views?:

a)Why the decoupling of Operator and Converter?
b)What is  with the Stack parameter to the getArity method?
c)rpneval.properties overriding  or repeating operator/operterms?

The way i see it, the operator knows better how to "prepare its operands". Thus, rather than feeding the operands converted by some (arbitrary) converter in which we might pick a wrong converter, why not couple them? I observed this:
1. Everywhere the operator is needed,  practically  the "same converter implementation" is set to that operator
2.The operator will have to recheck the operands again, it can't trust the converter to have done the right job to the operands, lest things will blow up!
3.Even at times we may have needed some other converter to convert some albeit weird operands, we are not spared from implementing the Converter interface, while  extending some base operator looks a lot straight forward.
4.Overriding the profiles? Rather than specifying  same operator and (may be same) opterms, the custom rpneval.properties should introduce additional operators and opterms not covered in default rpneval.properties, and overriding only those operators it sees fit.

And,
5. Where might the stack of operands be needed by the operator to determine its arity?
  
I made some changes to the base RPN to port to my much revamped mforms vis:

*Removed the converter interface and added convert method as a do nothing method to the AbstractOperator to be overridden by operators which need to do conversion before evaluation
*implemented eval in AbstractOperator to ensure conversion is attempted before proceeding to actual evaluation and introduced a method evalExpression for subclasses to implement to do actual evaluation
*A look at RPN suggests it should act more like a framework which you get the best out of it just by setting some few configurations, thus  the DefaultEvaluator implementation seems a good fit to evaluate any expression as long as powered with the right operators! So the Evaluator factory needs only to lookup  the configured operators.
*Changed loading of rpneval.properties files in EvaluationFactory to account for extensibility or overriding where appropriate.

With these, you can see the simplified configuration files attached for default_rpneval and custom_rpneval and the corresponding patch on rpn-eval to see the changes......
Best regards,
Donald

Donald Mteka
+255653105004

[Brent Atkinson]

Hi Donald,

Thanks for expressing your support for this. It helps to get a sense for what other community members are interested in and it's great you spoke up, whether you're in favor or not! :D 

I replied to the issues you raised and most of them were done intentionally, and the original implementation actually did things similar to what you suggest. More details in-line:

a)Why the decoupling of Operator and Converter?

This wasn't originally how it worked, and it was originally part of the operators. However, the conversions were often very similar for multiple operators and to reduce repetition, code-size and to allow reusing converters with extended operators, it was split and allowed to be mapped using the cofig files.
 

b)What is  with the Stack parameter to the getArity method?

There is a limitation with RPN that requires the arity of operators to be fixed, otherwise things get interpreted incorrectly. There are some techniques you can use to work around that, but you might need to inspect the stack in advance to verify the context. Normally it won't be used, but it's necessary in these less common cases.
 

c)rpneval.properties overriding  or repeating operator/operterms?

I originally wrote the config loading to load a default, then override this way, but it actually meant that I couldn't completely wipe the operators for a different usage (or to reduce overhead of unused ops). You can actually do both with the current implementation. Just use the same profile name in your overridden property file.
 

The way i see it, the operator knows better how to "prepare its operands". Thus, rather than feeding the operands converted by some (arbitrary) converter in which we might pick a wrong converter, why not couple them? I observed this:
1. Everywhere the operator is needed,  practically  the "same converter implementation" is set to that 

operator

 

This wasn't originally true, it only was when I merged the arithmetic, boolean and relation operators in a single class to reduce code size. It turned out that they were mostly similar anyway, but originally the conversion code was repeated in every operator. The way it is now, the api is flexible enough to write them either way without code duplication.
 

2.The operator will have to recheck the operands again, it can't trust the converter to have done the right job to the operands, lest things will blow up! 

You do? It is natural that type conversion and correct execution are closely related, but they don't have the same requirements. You should only have to recheck in certain circumstances, and the responsibilities are distinct though they appear to overlap a bit.
 

3.Even at times we may have needed some other converter to convert some albeit weird operands, we are not spared from implementing the Converter interface, while  extending some base operator looks a lot straight forward.

I'm not sure I understand, the Converter interface is extremely simple - one method. Also, the existing converters aren't final so you can extend them if you need to (or just configure them for use with your ops). I'm not sure I see the value in a base class here. You can also just not provide a converter at all and do it in your operator, the API doesn't require one... it checks if one is registered and uses it, otherwise it just invokes the operator directly.
 

4.Overriding the profiles? Rather than specifying  same operator and (may be same) opterms, the custom rpneval.properties should introduce additional operators and opterms not covered in default rpneval.properties, and overriding only those operators it sees fit. 

The existing scheme allows for this and it allows much better control over loading of configurations. Just use the default profile name in your overriden file and your settings will added into that profile.

And,
5. Where might the stack of operands be needed by the operator to determine its arity?

Variable length arguments lists.
 

I made some changes to the base RPN to port to my much revamped mforms vis:

*Removed the converter interface and added convert method as a do nothing method to the AbstractOperator to be overridden by operators which need to do conversion before evaluation
*implemented eval in AbstractOperator to ensure conversion is attempted before proceeding to actual evaluation and introduced a method evalExpression for subclasses to implement to do actual evaluation
*A look at RPN suggests it should act more like a framework which you get the best out of it just by setting some few configurations, thus  the DefaultEvaluator implementation seems a good fit to evaluate any expression as long as powered with the right operators! So the Evaluator factory needs only to lookup  the 

configured operators.

*Changed loading of rpneval.properties files in EvaluationFactory to account for extensibility or overriding where appropriate. 

With these, you can see the simplified configuration files attached for default_rpneval and custom_rpneval and the corresponding patch on rpn-eval to see the changes......
Best regards,
Donald

Thanks for taking a look and for the patch. I'll give it a look and see what makes sense.

Brent
 

[Donald mteka]

 Hi Brent,
 Thank you for your good and clear explanations for the design considerations taken into account.

 As for using the default profile name in overridden properties file  to extending the base profile, some few notes:
1) what happens to the evaluator implementation (unless we have no choice but one for evaluators)
2) what happens when you have more than one profile and they are intended to add to the default profile, surely they can't both use the same profile name, unless we have one profile per properties file.
 I had thought so at first, but your test sample properties file shaded some light from a different angle!
 Again you are forced to copy paste the operators&converters from default profile,
3)Wiping operators for a different use, that's what overriding is for. Reducing non-used ops overhead, lazy loading would do a good job, and after all, you already have all the properties loaded into memory! Should we have a pool of operators? Because implementations suggest they are thread safe, though not guaranteed.

About converters.. , Looks like it's not up to the operator to do the conversion! And indeed, the operator shouldn't even be concerned about the original format of the operands! Good point.
 If so, then, a clean and clear implementation would be, since there is one to one relation between profile and Evaluator, and the profile specifies the converter for every operator, then  it is the evaluator which should be given converters along with operators. Operators and converters are going to be thread safe and we should have a pools of operators and converters to pick form, rather than creating new instances  everytime a new profile is loaded to reduce overhead!.
 
Mobile app design considerations somewhat face challenges from good design principles in order to cope with memory and hardware limitations.
 So personally, i don't fancy these very much:
 =>interfaces with sole or no implementations.
 =>Implementations which look too much into the future or provide unused/non-useful alternatives or provide room for what isn't probably applicable for now (scoped outside and beyond). Perhaps  good documentation/comments could do better to retain the concept or idea.

Well done Brent, keep up the good work.
Best regards,
Donald.

[Øystein Lund Rolland]

Hi Brent! Could you give some instructions in how to run the midlet and hook a debugger to it?

Thanks

Best Regards

Øystein Lund Rolland

Centre of International Health (CIH)

OpenXData - www.openxdata.org

oystein....@cih.uib.no

+47 92 86 26 56

[Brent Atkinson]

Øystein,

Sure, it's actually not too different from the existing setup.

Build the project with:

$ mvn clean install -Ddebug
$ cd mforms-midlet
$ mvn j2me:run -Ddebug

The reason you need to specify that flag is that you want debug symbols and a non-obfuscated jar. I'll be documenting it on the wiki once it's integrated.

Brent

[Øystein Lund Rolland]

Yeah, i actually did exactly that, but didn't know you needed the capitol D before debug. Thanks for directions!