task forces

[mdipierro]

I think we need to build two task forces.

1) to build a CMS

2) to build a eStore

the more overlap the better. We need two project leaders and
volunteers. I also suggest starting by creating google docs to gather
requirements.

Lots of people needs these, including me.

Massimo

[Mr admin]

I like the idea! I'd like to be a tester, documenter for the eStore.

Sterling

[eric cs]

I am in...but no knowledge, just wanna help and learn on the process
if that is possible, count with me.

[Yarko Tymciurak]

Those are bigger, more ambitious projects.

We could start with something shorter, just to work out the task force processes....

Perhaps a web2py resources site, an update to the appliances app could be the first part of that (and an update to it).
This will give us relatively little to do, and we can work out what will work:

I would like to see "regular" meetings (IRC), and _real_ distance, on-line code sprints... so that a 2 hour session will find everyone coding a piece, and a leader merging and running it live for all to review, update, etc.   (leader to push up to a launchpad, or mercurial).

One of the process things to work out:  stay launchpad, or move code.google.com / mercurial.

The latter would give us (if they've worked it out) a code review site, which would be a great way for task force to work asynchronously (e.g. in between code-sprint meetings).

Code sprints would be useful - if the balance on a team was 3 / 2  or so of experienced python-web2py-ers, vs people wanting to learn, stretch it would be a great way to regularly have a place to join in --- real "community" stuff.

How does this sound?   A simpler job to work out the basics of the working process, find what will work for starters.

- Yarko

[Vidul]

I've always been on the opinion that MVC like WEB2PY (i.e. a normal
MVC) is a MVC and a CMS in one (probably I am missing some end-users'
points of view).
But eStore - that makes a lot of sense to me, so I am for it.

[eric cs]

We have to beat them...hehehe
Rails for Spree and Magento for Php/Zend.
At least Magento for inspiration.

> > > Massimo- Hide quoted text -
>
> - Show quoted text -

[nathan.ms]

I wonder if we could use satchmo django project for the estore?

[Yarko Tymciurak]

I think for a CMS, defining what to do, how it would look initially, and it's structure could take some time to review the "best" (or most used) CMS's and what they offer.  The basic structure should not be too hard to start (Massimo has started several times).

A wiki is probably a core component of this, so considering the components of a CMS might spawn several projects.

I'd just want to be sure to start with something that will work, will show how to work in sprint teams, and will produce results rather quickly.  Then more ambitious projects will have a way to gain traction.

[mdipierro]

I think it would be a good exercise to start from there. I do know if
sachmo has this but we it would be nice to a web service layer so that
users can develop frontends in html (the default) or Flex (via
standard APIs provided by the system).

On Jul 10, 4:11 pm, Yarko Tymciurak <yark...@gmail.com> wrote:
> I think for a CMS, defining what to do, how it would look initially, and
> it's structure could take some time to review the "best" (or most used)
> CMS's and what they offer. The basic structure should not be too hard to
> start (Massimo has started several times).
>
> A wiki is probably a core component of this, so considering the components
> of a CMS might spawn several projects.
>
> I'd just want to be sure to start with something that will work, will show
> how to work in sprint teams, and will produce results rather quickly. Then
> more ambitious projects will have a way to gain traction.
>

[mdipierro]

magneto is nice.

[Yarko Tymciurak]

for me this is a meta-activity:  porting as an ending action, starting with analysis of other's solutions.

Analyze (reverse engineer) / restructure (for web2py) / adjust design / port is a useful idiom to have down.

[Yarko Tymciurak]

On Fri, Jul 10, 2009 at 4:14 PM, mdipierro <mdip...@cs.depaul.edu> wrote:

I think it would be a good exercise to start from there. I do know if
sachmo has this but we it would be nice to a web service layer so that
users can develop frontends in html (the default) or Flex (via
standard APIs provided by the system).

...not clear what you meant - start from a wiki?  start from a CMS basic structure?

[eric cs]

Flex and Flash front end kick ass.

> > > - Show quoted text -- Hide quoted text -

[mdipierro]

I meant the store is a special class of a CMS so there should be some
overlap.

On Jul 10, 4:22 pm, Yarko Tymciurak <yark...@gmail.com> wrote:

[Yarko Tymciurak]

I've just _just_ started running the flex for Linux to see if I can make it thru Eckel's "First Steps in Flex" book, if the Linux alpha is up to the task...

[viniciusban]

On Jul 10, 5:49 pm, Yarko Tymciurak <yark...@gmail.com> wrote:
> Those are bigger, more ambitious projects.
>
> We could start with something shorter, just to work out the task force
> processes....

Yarko, I agree with you.

> How does this sound?   A simpler job to work out the basics of the working
> process, find what will work for starters.

It sounds great for me.

If we cannot do something small and simple, we shall not do something
bigger, too.
The problem is not just develop. The *real* problem is communicate,
integrate and not give up.

In addition, there are many people learning python and web2py as well,
like me.
I am a professional developer, but I don't have experience with this
sort or tools.

If we start small I am on it.

Massimo, how about creating a sheet (google docs, maybe?) to allow
people to sign in telling what role would like to play in this
project?
We don't need just developers, right?

I see that any project needs the "Benevolent Dictator for
Life" (BDFL), like Guido van Rossum or Linus Torvalds.
We need someone to make choices. We need someone to select features to
be implemented (the Product Owner, in agile terms).

And we need some coordinator. We need a leader, someone to head teams
to a commum goal (the coach, or the scrum master in scrum jargon).

So, I suggest the sheet, Massimo.

--
Vinicius Assef.

[mdipierro]

I agree but I want to be a contributor not the coordinator or project
owner.

Massimo

[Yarko Tymciurak]

SO I don't think we should have a signup sheet....

I think it should be more virtual-open spaces style:  a regular time IRC, and whoever shows up takes on a task...

The real "work" will be syncing everyone up to the same version code, and working and re-syncing every 15 minutes (I would like to drive a 15 minute coding rule:  no longer than that before we get some version of running code - even if only failing tests - and work in those kinds of increments)

That means, over a 2 hour sprint, we should have about 1:00 - 1:15 of actual coding.  With integration / merging, probably 4-6 coders per sprint.  More than that would probably need sub-groups of 4-6 (1-2 coordinators / captains).

As slow as bazaar is, i think either git or mercurial is the way to go - since mercurial is traditionally more portable (and what Python project has decided to move to) I suggest that.

We should start w/ a mercurial setup session....  then we can announce a first sprint session.

Who's in for the setup?

One of the things we'll have to work out:  how to work:  pull from each other, or push to branches, and a captain pull, merge, push to trun and give to people --- that latter part will be the time limiting factor; if it's too much coding at a time, the merges will get messy.  If a merge results in failing code, that will have to be addressed first.  

Time zone may be the other factor to consider...

Before setup and coding, working out basic specs (coding  / design tasks) should happen...

Other rules I propose:   If a sprint can't get code running w/ 15 minutes of coding, then into 1hr design session;
If design session can't solve it, then move up to a modeling session (1 week chuncks);  if that doesn't solve it, then up to a problem definition stage (2 week-1 month chuncks).

Who's still up for this?  In for the first?   First session would be problem definition, and initial model description (sentences; I don't want to get into UML models unless the complexity warrants).  Then we decide if we have enough to do some initial coding, or need to define prototyping coding sessions to flush out what we want to do...    Then the next IRC will be working out how we share / exchange code in such a short cycle (15 minutes, repeated thru 2 to maybe 4 hr sprints).

- Yarko

- Yarko

- Yarko

[mdipierro]

Something like this to start with....:

db.define_table('category',
Field('name'))

db.define_table('product',
Field('name'),
Field('dategory',db.category),
Field('description','text',represent=lambda value: WIKI(value)),
Field('price','double',default=10.00),
Field('quantity_in_stock','integer',default=0),
Field('on_sale_since','datetime',default=request.now))

@service.xml
@service.json
@service.csv
@service.xmlrpc
@service.jsonrpc
@servcie.amfrpc3('store')
def list_categories(): ...

@service.xml
@service.json
@service.csv
@service.xmlrpc
@service.jsonrpc
@servcie.amfrpc3('store')
def list_products_by_category(id, price_range): ....

@service.xml
@service.json
@service.csv
@service.xmlrpc
@service.jsonrpc
@servcie.amfrpc3('store')
def list_products_by_keyword(keyword, price_range): ...

...

[Joe Barnhart]

I think its a complete diversion of effort and a waste of time.

The reason we don't have meaningful apps on web2py is because nobody
can figure out how to use it. The documentation SUCKS. Hello??!?
Haven't we had this discussion endless times already?

We are the same group who couldn't create our own WIKI in web2py so we
could have a PLACE for documentation. Instead of fixing the wiki
we're going to hike the banners and storm the walls of other platforms
by doing our own CMS?

We need cohesive documentation so we can grow the pool of web2py
users. Useful meaningful applications will come if we have a user
community with depth. Which we DON'T at present.

-- Joe Barnhart

[Yarko Tymciurak]

Hmmmm....

The process of a sprint will show more clearly what kinds of things need to be addressed in documentation.

I don't agree - I don't think this will be a diversion;  I think it will be enlightening (and possibly show up things
people from various aspects didn't expect).

[mdipierro]

I disagree Joe.

The new book is coming out in less than one month. It will cover all
the new features. I have posted some of the chapters already.

Massimo

[Yarko Tymciurak]

... I personally don't want to start w/ CMS or eStore.

I'm already uncomfortable with the immediate jump to solution; an immediate "here's how you can do it!", without allowing for the necessary and normal process of "what do we want this to do?"  followed by "what are the ways this can be done?"... and the choice to "let's do it this way...").... 

I continue to  think sometihing more focused, narrower in scope is a better first target.

[mdipierro]

Let's keep things focused. Everybody can do what he/she likes to do. I
need an eStore. I know of other people on this list who need an
eStore. The eStore must include a CMS. I just suggested we join
forces. Nothing is set other than the requirements of those who want
to join. I have mine but they are not set in stone.

I really like your idea of an IRC meeting although I am quite busy
this week and then I will be traveling for a while.

Massimo

On Jul 11, 12:08 pm, Yarko Tymciurak <yark...@gmail.com> wrote:
> ... I personally don't want to start w/ CMS or eStore.
>
> I'm already uncomfortable with the immediate jump to solution; an immediate
> "here's how you can do it!", without allowing for the necessary and normal
> process of "what do we want this to do?"  followed by "what are the ways
> this can be done?"... and the choice to "let's do it this way...")....
>
> I continue to  think sometihing more focused, narrower in scope is a better
> first target.
>

[JohnMc]

Joe --

I disagree as well. Even though I have said more than once docs are a
weak point. But it is being addressed. Might I suggest, Massimo
released 3 chapters of the new book. Have you reviewed them and
possibly sent in corrections? Proof's in the pudding.

Yarko, rest --

Want something focused, gets out the kinks on process and has
something to show for it in the end process?

Why not turn the editorial proofing of the V2 of the book into a
series of sprints? If nothing else it will validate the 'process' for
everything else going forward. If Massimo approves, its his IP.

As to projects to tackle. I see nothing wrong with either CMS, Wiki,
or eStore. If you ran these suggestions thru a UML you will end up
with some constituent subcomponents.

* editor come tag tool. Ends up being common to all three.
* intelligent storage. A means to properly categorize content, filter
it, sort it in a common way. Maybe an XPath like metaphor higher level
than the DAL for most common searches? DAL directly for more
sophisticated queries. Common to CMS, Wiki, Blog and catalog
descriptions in an eStore.
* Calendar function. An iCal based engine plus a base level class for
display. Common to CMS, Wiki, Blog.
* Workflow engine. Leverage off the cron functionality but extend it
to trigger tasks in sequence and in parallel as the work flow
dictates. Tasks would validate predecessors are complete. Common in
CMS, eStore.

With those subcomponents in hand tackling the higher level projects
start with around 50% of the work already done -- once. This also
gives those interested exposure to these tools before launching a
larger project.

JohnMc

On Jul 11, 11:34 am, Joe Barnhart <joe.barnh...@gmail.com> wrote:

[mdipierro]

I like this very much. About your calendar project:

http://www.bytecyclist.com/SourceCode/jMonthCalendar/1.3.0-beta/Demo.html

massimo

[Joe Barnhart]

OK Massimo --

I'm not going to beat my drum to death, but your new book is not what
I meant by documentation. We have AlterEgo, the book, the examples,
this forum, "web2pyslices", etc. etc. etc. Each occupies a tiny space
in the totality of documenting web2py. We decided a wiki could
subsume pretty much all of the "unofficial" sources of documentation
and provide a more focused place to learn and share w2p information.

The wiki was a failure in that it never attracted developers to fix
its shortcomings and thus never attracted anyone to use it for docs.
The wiki was not deemed a very complicated project, yet as a group we
did not succeed in creating a wiki. (The wiki itself was deemed to be
"strategic" enough that it was important not to use someone else's
wiki but rather show we could do it in web2py.)

Now I read that we want to start more ambitious projects for a
storefront and a content management system to back it up. What's
wrong with this picture?

The people who are actively participating in web2py are about a dozen
developers (or fewer) and they're doing all the work on web2py as well
as all the apps. Many (perhaps most) of the thousand plus "signups"
on the forum represent people who came here, got discouraged, and
wandered off to solve their problem some other way. Or, like me,
landed here in purgatory never quite making it to software heaven but
seeing the promise of those pearly gates and refusing to leave.

I've been working on a project on and off (as my day job permits) but
I have to say it is very difficult going because there are too many
scattered sources of information. And the information comes from
different "epochs" of web2py which provides conflicting ways to
accomplish a task (e.g. T2, T3, auth, crud, etc. all have many
variations). All of those variations show up when you search for a
phrase to find out how to do something. It is very slow going.

If the slow learners (like me) were ahead of the power curve instead
of always chasing it, you would have many more than a dozen active
developers on web2py. That's all I'm saying. Build the base, then
the code will flow.

-- Joe B.

[Mico Siahaan]

Imho good docs is one factor for popularity of a framework. The other important factor is it has been used to build 'killer apps'. Massimo, I read that web2py has successfuly used to develop enterprise apps. Let's say they want to keep the apps closed source, at least nice articles contain succes stories would be nice to convince potential users of web2py. Yes, I am a marketing guy and good brochures always work in my job. :)

Mico
Powered by Telkomsel BlackBerry®

[Lincoln_Consulting]

I diasagree too.

I need a web2py helpdesk.

If enough user community is attracted to web2py + GAE, I can get my
helpdesk built.

Also as an architect of the language Massimo, the focus should be;

1. Documentation

2. Attracting developers to web2py

3. After the founder scenario - Creating a community / Foundation like
Debian

A one man dictating, i need "estore + cms" out of the blue, seems
plain silly.

We can take a lot of good things from Jquery, Debian etc

Thanks

[mdipierro]

Joe,

I have to disagree again. We have a lot of developers, more than a
dozen. Here they are:

http://web2py.com/examples/default/who.html

and a log of the people who contributed are very skilled in web2py.

The wiki did not was very well but that is not a concern of mine. As
far as I am concerned the book is the source of documentation.

You are confusing experimental stuff with web2py. T2 and T3 are poorly
documented by they are not and never were part of web2py. T2 was
deprecated long ago. T3 was an experiment. One day it will be
rewritten and better, perhaps integrated with jpolite and/or kpax. The
"official" Authentication method is very well described in the new
book and the chapter I posted here.

The only feature of web2py that is not documented well are web
services. I will finish this missing chapter by the end of the month.

AlterEgo is a place for me (and you) to post brief articles. Some are
current, some are obsolete, but they all talk about recipes that work.
I just reviewed all of them and I found that only a dozen of them
describe recipes that are not discussed in the book. I will include
them in the second edition.

Massimo

[Francois (Jersey)]

Back with an old query, in order to deal with an e-store, we would
need to deal with numeric, as we need to deal with prices which are
monetary amounts in multiple currencies.

I can not remember where we are with numeric implementation?

For example in SQLalchemy, numeric is defined as

class sqlalchemy.types.Numeric(precision=10, scale=2, asdecimal=True,
length=None)¶
Bases: sqlalchemy.types.TypeEngine
A type for fixed precision numbers.
Typically generates DECIMAL or NUMERIC. Returns decimal.Decimal
objects by default.

http://www.sqlalchemy.org/docs/05/reference/sqlalchemy/types.html?highlight=decimal#sqlalchemy.types.TypeEngine

[Francois (Jersey)]

For example in Postgresql and MySQL , we Monetary Types:
http://www.postgresql.org/docs/8.4/static/datatype-money.html
http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html

I really believe that we should store monetary amount using the
monetary amount available in the database if available, as else it is
not robust enough to be an enterprise framework

[Yarko Tymciurak]

My mind immediately JUMPED at JohnMc's suggestion of a calendar -

Useful everywhere;  useful in CMS, in community sites, even in eStore where you sign up for events (as opposed to shippable products - e.g. seminars, haircut appts, etc.)

Massimo's like just gives the front end - all that's left to do is a base backend (I would guess)....

This seems simple enough to do little more than flush processe, but yet result in a useful module.

Who'd like to sign up for an on-line IRC coordinated series of sessions & code sprints?   They will seem boring, as working out the mercurial push/merge/pull  run cycles, and getting them short enough so that things actually feel and act like sprints may at first be a distraction.

3 of 4 hearty souls?

I would guess 2 or 3 sessions;

product would be a web2py calendar scheduling module AND a guidesheet for online sprinting / projects.

- Yarko

[mdipierro]

The new DAL will have a Numeric type. It should be possible to develop
the eStore app independently on this issue (assume double) and then
just change the field type when the new one becomes available.

On Jul 12, 1:26 am, "Francois (Jersey)"

> http://www.sqlalchemy.org/docs/05/reference/sqlalchemy/types.html?hig...

[Hans Donner]

How will the new DAL replaces the functionality of the current and
experimental SQLCustomType?

[JohnMc]

Yarko,

I am game. Just be warned, I code slow. I don't have all of Web2Py in
my head like some of you sharper knives in the drawer! :)

I think it would still be useful to sprint through the book as a proof
of process. But I am flexible.

If we tackle calendar Then I might offer a few suggestions for
requirements -

* Views available for day, week, month, year. Plus a stub for custom
views.
* Configurable attributes -
+ time slice of any span down to 15min.
+ user definable classification of event types.
+ user definable coloration of the classification.
+ user definable default view.
+ user definable mail address.
* Events that -
+ usual details, time, place, date, interval, recurring.
+ can have predecessor/successor tags. (w)
+ triggerable. Mark the event to launch an action thru cron (w)
+ Notification either by mail or notification if user is also using
Web2Py calendar.
* Variable visibility of events (public, private, confidential, etc)
* Export/import calendar via RSS, XML, iCal.
* Usual tools, copy, paste, delete, bulk move
* Group functions -
+ view participants public calendar events.
+ assign/remove a new event to all in a group. With confirmation
acceptance.
+ find first available date based on time interval for all in group.

(w) - Would be part of a workflow controller. But hooks are available
in calendar.

Probably missed some pieces. I just pulled the major attributes off
the PlOne CMS calendar function. A repeat of this is available --
http://docs.google.com/View?id=ddfwjgjr_68cb6fk4gr

I'll open it up to invitees to those interested that want to add/edit
the requirements.

JohnMc

[mdipierro]

I do not know. Anyway, that functionality is undocumented because
experimental and therefore I do not promise it will be backward
compatible. There will be a way to do it. If people like the current
syntax we can try preserve it.

Massimo

On Jul 12, 9:19 am, Hans Donner <hans.don...@pobox.com> wrote:
> How will the new DAL replaces the functionality of the current and
> experimental SQLCustomType?
>

[mdipierro]

One thing is important...

Build each controller in a controller with its own name (do not call
it default, call it calendar for example).

Assume a db connection created by db.py but put the models for your
component in db_calender.py.

This will simplify merging of components.

Massimo

> the PlOne CMS calendar function. A repeat of this is available  --http://docs.google.com/View?id=ddfwjgjr_68cb6fk4gr

[Hans Donner]

for me no need to have the same syntax and in that regard to be
backwards compatible. However, I do like the functionality offered by
it.

[Yarko Tymciurak]

On Sun, Jul 12, 2009 at 9:45 AM, mdipierro <mdip...@cs.depaul.edu> wrote:

One thing is important...

Build each controller in a controller with its own name (do not call
it default, call it calendar for example).

Assume a db connection created by db.py but put the models for your
component in db_calender.py.

Yes - that makes sense...

[weheh]

I'm late to this party because I've been on the road and
incommunicado, but here are my 2 cents:

- CMS: this is a critical app and one of the reasons I ended up
finding web2py to begin with, even though web2py is neither a CMS nor
is there a production-worthy CMS (no slur against KPAX) associated
with web2py. CMS is an important functionality for just about any
website, so this is definitely a high-priority app to have open-
sourced for web2py.

- estore: A production-worthy estore would be quite nice. Especially
if it would be easy to tie into one's own web2py db of products.
Thumbs up to this idea, too.

- Wiki: I agree with Joe on this one. Why the heck hasn't the web2py
wiki gotten more attention? Why doesn't it a kick-ass web2py app? Why
aren't people building out the info in it? What does that say about
this community?

- Calendar: I just finished a calendar-based scheduling app for a
client. It was fun and had its challenges. I'm debating adapting it to
one of my own websites. But I'm also looking deeper into Google
Calendar. Frankly, it looks like it would make more sense for an
example of web2py tapping into Google calendar. The philosophical
issue is that most people won't have multiple calendars going at once.
Google has achieved black hole mass and has already won the email and
calendar battle (even relative to Microsoft). How could web2py even
make a dent, here? Why would anyone put their calendar on someone
else's website when they already have it in Google Cal, MS Outlook,
their Palm Pilot, or their Blackberry? I vote NAY on developing a
calendar app.

And now the best saved for last:

- Medical records keeping: I've seen some postings about this on
web2py. This, to me, is the *killer app*. Since I first learned of
web2py I've been threatening my friends that I was going to do
something about medical record keeping. Web2py seems like the obvious
choice for implementation. Let me explain ...

For most people, privacy, cost, and ubiquity are the key issues
surrounding medical records keeping.
- Privacy: web2py offers privacy because it can run on a USB memory
stick. In other words, you can keep your records on a memory stick and
completely off the internet or your PC. What could be more secure?
Google offers free medical records keeping. I tried it. Knock on wood,
I'm healthy, so there's not much data I need to enter into Google.
Nevertheless, there's no way in hell I'm going to give Google my
medical records. (I know, this sounds inconsistent when correlated
against my comments about the calendar app above. Still, medical
records are more sensitive than when I have to carpool my kid to
school, right? And Google already knows too much about me, so there!)
- Cost: how about free? Most medical records systems cost $100K+. Why?
Beats me. Who pays for it? We all do. Sure, there is the issue of
integration with equipment and legacy records. But those issues aren't
that difficult to overcome. Really, the issue of medical records
keeping is more political than technological, IMHO. (Call me naiive,
but there are 3 docs in my family and I've talked to them, most of my
best friends are docs and I've taoked to them, I've talked about this
issue with all my own personal docs, I've talked to people in
government who are responsible for medical records keeping, and to the
IT people in docs offices and at hospitals who are responsible for
medical records keeping. My conclusion is that it's a political issue
-- government, office politics, big insurance politics, and medical
community politics.) The way to kill this issue is to make it free.
Free as in $0.
- Ubiquity: Free is good. Free is different from cheap. Free spreads
fast. Free spreads everywhere. Something like >70% of doctors offices
in the US don't have electronic medical records (EMR) because it's too
expensive. The Obama admin is budgeting greater than $10B (that's
billions with a B) to make electronic records ubiquitous. For us
Americans out there using web2py, this hits us in the wallet. Frankly,
I'm appalled that anyone thinks it will cost $10B+ to do this. As
relieved as I am that Obama is president (vs. the previous jackass), I
think it's an absurd use of my taxpayer's dollars to subsidise the
medical and insurance industries with costly, yet easy to implement
software. So I see it as almost a patriotic duty to come up with a
strategy that subverts the bureaucracy's tendency to spend my hard-
earned money.

Towards that end, web2py is an unbelievable opportunity for medical
record keeping because it gives us, the consumers of medical services,
the opportunity to own and control our own medical records. Web2py is
unique among potential implementations in its ability to run off of a
USB memory stick. As such, the issue of privacy is moot. The patient
can keep his/her own medical record off-line and under lock and key if
they so choose.

Distribution of a web2py medical record app would be free. If the
customer was too poor to have a computer, there could be sites that
hosted the medical records and web2py medical app. But frankly, even
the sickest patient could fit all their medical records on a 100MB USB
memory stick, which is basically free.

Patients could download the app (with web2py and SQLite included) onto
a local machine, get the doc to copy their record into it, and then
bring the USB stick to the doctor's office where they could enable
their doctor to see select portions of their record. Same goes for
insurance companies and pharmacies. If online, then access could also
be controlled using the auth and CRUD functionality.

The potential for positive publicity for web2py for a medical records
app would be, frankly, priceless. And the savings to the government
and medical community would be in the $Billions. As for the insurance
and pharma companies, screw them (after all, they screw us all the
time). They would benefit from cost savings, too, but who cares?

So there's my 2 cents. I'll get off my soap box now. Comments and
rants are welcome.

[Yarko Tymciurak]

Simple point about calendar:  not sure you can (or would want to) use google calendar as part of a estore - that is, to sell time (coaching, seminars, haircuts, whatever...)

[Yarko Tymciurak]

....but I think I generally agree w/ you that - other than basic correcation, there is probably not a compelling reason to replicate the whole kit-and-kaboodle....

[JohnMc]

Weheh,

I presume your American based on your ISP.

There is a little issue about medical records in the US. Its a little
law called HIPPA. One of the considerations is that there are severe
requirements vis a vis security of medical records data. I am not
saying Web2Py could not meet them, but one, upon releasing such an app
might consider lawyering up and having sufficient legal insurance if
there is ever a breach.

Which by the way, try getting your records from your GP. Most
practitioners consider your records their property.

Something to consider.

JohnMc

[Yarko Tymciurak]

without considering US or commercial use, there is an open sourced med records system that I believe the WHO is involved in, which I discovered thru a world health thing I found Bill Clinton's foundation involved in - you might want to prefer to collaborate there (as it stands to have significant impact):  http://openmrs.org

this just serves.... I'll dig up the links, if anyone is interested.

[Yarko Tymciurak]

On Sun, Jul 12, 2009 at 10:28 PM, Yarko Tymciurak <yar...@gmail.com> wrote:

without considering US or commercial use, there is an open sourced med records system that I believe the WHO is involved in, which I discovered thru a world health thing I found Bill Clinton's foundation involved in - you might want to prefer to collaborate there (as it stands to have significant impact):  http://openmrs.org

this just serves.... I'll dig up the links, if anyone is interested.

--- sorry; just ignore this last line (above)...

[weheh]

Indeed, any EMR (electronic medical record) system must be HIPPA
compliant. There's no reason web2py why an online web2py
implementation shouldn't be able to achieve a level of security that
would achieve compliance. In fact, I would expect that in the long
term, an Open Source web-based EMR system based on web2py could
probably achieve a higher level of security than a mom-and-pop shop
web-based EMR system. Also, nobody can crack an EMR that's solely
resident on a USB memory stick unless you pick that person's pocket or
break into their home.

As far as getting the doc's info into your record, there are two parts
to the answer. First, docs are willing to share part of their EMR with
the patient. Just as the patient is willing to share part of their
medical history with the docs. So ownership is distributed.

But indeed, I am suggesting a paradigm shift away from a monolithic
medical culture where the patient is a piece of meat with no ownership
of their personal data, to an individual with data ownership and
responsibility. After all, patients already have ownership of their
data. It's just that it's not in electronic form. Therefore, they have
to repeat it every time they see a new doctor.

So any EMR system based on web2py needs to have compartments: part of
the record is patient only, which is owned by the patient. Part is
doctor only, which is owned by the doctor. Part is insurance only,
which is owned by the insurance company. Etc. Different parts can be
shared between different parties, entirely dependent on the owner
allowing the sharing and the receiving party being priviledged and
certified to access such info.

The point of HIPPA is not to make it impossible for anyone to do EMR.
It's to protect the privacy of the info. For what technical reason
should a web2py based EMR system NOT be able to achieve said
compliance?

> > choice for implementation. Let me explain ...- Hide quoted text -
>
> - Show quoted text -

[Benigno]

Hi, just to add my opinion to this:

- I agree with Joe, in that documentation needs to be the first base.
Proof of it, is that even though, it is probably writen all over in
different places, I have had to come to the T2, T3 conclusion that
Massimo so clearly writes here, by deduction, and not by reading some
red bright neon sign that would have saved me from putting any time
into trying to get to know those products.
- However, I have been seeing improvements, in the documentation
little by little, and if the book is coming out, then I'd rather not
fret about it, until I have it in my hands and use it daily. (I am a
forgettable person, and need these books not only for learning but as
constant refference).

- That said, I think that there is more to making this effort than
creating an app. And I think that in there Yarko is right to the
point, and only for that it should already be worth the while for all
of us. If only it helps us to build a basic structure that we can
further refine as a means for collaborating in developements, and
possibly in documentation... Well, to me, thats the goal. Take any
project as an excuse.

- Regarding what project to take... well, I highly doubt that we will
have any kind of success in building anything big by any standars in
this initial go. But as I said, thats beyond the point that I see as
main goal to this initial effort. However, I'd still say go for
something small, as the need for organisation on something bigger is
so much greater, that I doubt we would reach the developement phase in
one piece, and a fruitless project is discouraging to all.

- I also have to say, that I do like Johns idea of going through the
book, although, I think it achieves a different goal than setting a
collaborating/developement/documenting environment.

- As for a callendar, well, thats something I have been missing in
several of my projects, and its easy to see a fit to it to almost
anything, from event management to time resource availability. Even a
calendar app may get big though, so again, I'd start with something
small.

- Regarding CMS and eStore. Well.. a CMS is a monster of its own, but
I think that one needs to consider, what effort will be put into
maintaining, and documenting it later on... onto adapting it and
updating it as web2py advances?. That's actually the main reason why I
wouldnt try to create a full fledged CMS, its kind of diverting
resources from web2py if you want it to be alive, and what point is it
in creating it as a whole if we do not plan on maintaining it as we go
along?. I really think that both CMS and eStore, really only make
sense as proof of concept, and not as full fledged applications, just
as a basis to go on from there.

Anyway, all that said, I am in... however I have to say just like
John... I am a slow programmer. My main area of expertise is actually
ERPs.

Benigno.

> the PlOne CMS calendar function. A repeat of this is available  --http://docs.google.com/View?id=ddfwjgjr_68cb6fk4gr

[Matt van Gerwen]

Dear Massimo,

First of all. I like to thank Massimo and developers for doing a great
job. I'm still looking forward that i will finish my web2py apps. You
all are putting an huge amount of energy into web2py. I see several
features emerging and growing to maturity. From T2, T3 to CRUD etc.
Web2py is in an developing phase (like evolution) into a industry-ready
framework. In the beginning the security was already high and profound
in web2py. (unfortuantily the use of primary keys is limited to an
"id".)

Is there an overall plan like a business plan or a project plan. It
gives an idea what is ahead, which turns are good for the development.

I can imaging that you need a CMS and a eStore.

What I find very difficult (however: I should not try to develop a
software application) is the controllers setup: every controller has one
html page. Is there a way to put more than one controller in an html
page. Or is this simple done by extending the html page to alter the
http://website/app/function/agruments ?

With kind regards (sorry for my english)

Matt van Gerwen

[JohnMc]

Weheh,

On Jul 13, 12:19 am, weheh <richard_gor...@verizon.net> wrote:
> Indeed, any EMR (electronic medical record) system must be HIPPA
> compliant. There's no reason web2py why an online web2py

I see no reason that web2py cannot be HIPPA compliant. My point was
more in relationship to your comment on the costs of such systems. The
$100k per installation sounds about right. But slicing the onion, the
allocation of that charge is probably 60-70% for preparatory legal
defense. The more a particular EMR grows in installations the greater
the risk is that a breach will occur.

> But indeed, I am suggesting a paradigm shift away from a monolithic
> medical culture where the patient is a piece of meat with no ownership
> of their personal data,

I have had medical care in Russia and that is the type of records
management they have. Its the patients responsibility to maintain
their long term medical records. The doctors/hospitals also keep
records but only of the procedures they alone performed. Considering
the cultural nature of the US, it seems counter intuitive that if
privacy is in such high esteem that medical records are not the
personal property of the patient. I am with you there.

> The point of HIPPA is not to make it impossible for anyone to do EMR.
> It's to protect the privacy of the info. For what technical reason
> should a web2py based EMR system NOT be able to achieve said
> compliance?

Again, based on what I have developed with Web2Py I have no doubt it
can be done. The issues are external to the technology. Lets say you
write the world's best EMR. 1) It being open source does not protect
you from the stupidity of the user base. You can still be sued. 2)
Even if in your documentation you state that to use the software the
user is required to use only a secure USB key. Many won't as they
simply did not read your document and purchased a $9.99 USB special.
So when their medical records end up on some website they are going
after you because it is 'your fault'. 3) You also sign yourself up for
keeping current on medical record security mandates.

I don't want to rain on the parade. Its an ambitious undertaking and a
worthy cause to pursue. But the downside risks would not let me sleep
at night.

JohnMc

[mdipierro]

Yes. Multiple controller can specify the same view with

response.view="myview.html"

or

with

return render.response("myview.html", dict(....))

[weheh]

JohnMc - Thanks for your thoughtful feedback. I'm not an attorney so I
can't tell you the liabilities of using OpenSource software for EMR.
But I'm sure this issue can also be handled by the appropriate
authorities. However, I think we're getting off topic. Of the various
projects that have been discussed in this thread, I think the first
couple are where those who are so inclined in this group should focus
their immediate attention and efforts, namely CMS, eStore, Wiki. I do
not have the time to make a meaningful contribution to such endeavors.
I save what little time I have available to help Massimo get the new
doc reviewed and cleaned up. IMHO, that's what'll have the greatest
positive impact for web2py.

[JohnMc]

Same here Wheh.

[Yarko Tymciurak]

On Mon, Jul 13, 2009 at 4:46 AM, Matt van Gerwen <matt.va...@gmail.com> wrote:

Dear Massimo,

First of all. I like to thank Massimo and developers for doing  a great
job. I'm still looking forward that i will finish my web2py apps. You
all are putting an huge amount of energy into web2py. I see several
features emerging and growing to maturity. From T2, T3 to CRUD etc.
Web2py is in an developing phase (like evolution) into a industry-ready
framework. In the beginning the security was already high and profound
in web2py. (unfortuantily the use of primary keys is limited to an
"id".)

Is there an overall plan like a business plan or a project plan. It
gives an idea what is ahead, which turns are good for the development.

I can imaging that you need a CMS and a eStore.

What I find very difficult (however: I should not try to develop a
software application) is the controllers setup: every controller has one
html page. Is there a way to put more than one controller in an html
page. Or is this simple done by extending the html page to alter the
http://website/app/function/agruments ?

Have you looked at the jpolite examples?

You can render several controllers at the same time in one HTML page (Massimo answered how to show one controller at a time using one view for many controllers)

See:  http://www.web2py.com/jpolite/default/main#t2

(the second tab shows how to render a controller per frame)

- Yarko

[__future__]

I realize I am a little late to this discussion but after reviewing a
lot of the messages in the group, searching the web resources
(purchased manual, cookbook slides, alterego, etc.) and playing around
with the framework for a few weeks at work in my spare time, I have
some observations:

- Documentation should be the number one priority. I realize there is
movement on this but I am not clear on the specifics other than Sphinx
being mentioned, which is really good to hear.

- Building out the resources for prospective web2py developers should
take precedence over anything like CMS or eStore (though I personally
would benefit from both of those). Things like http://www.djangosnippets.org/
for web2py would go a long way to spreading the gains from any/all
projects around to the larger community. Something like Railscasts
would also be a good example of something that could be both a project
and service to newcomers.

I think the idea of cleaning up the appliance app is a good idea and
inline with the above.

I am still trying to make myself fluent with web2py and even though it
is a lot simpler to pick up than Django, for example, I felt a lot
more secure in the Djangoverse because of the kick-ass documentation
and community support. Whatever else you want to say about the Django
folks, they are definitely organized and they serve up some nice
things to their community.

A laundry list of complaints would sound like nitpicking but little
things can really annoy... like when i am copying/pasting code form
the how-to section of the web page and all of the string quotes come
over like `some string` so I have to manually edit every string I just
pasted.

Thank you to everyone for their hard work on web2py, especially
Massimo. I really like the concept. The completeness of it all as a
package.. the practically zero configuration factor and many other
niceties put it in a class alone among the many web frameworks out
there right now.

--
KW

[Fran]

On Jul 22, 6:02 am, __future__ <wrigh...@gmail.com> wrote:
> I realize I am a little late to this discussion but after reviewing a
> lot of the messages in the group, searching the web resources
> (purchased manual, cookbook slides, alterego, etc.) and playing around
> with the framework for a few weeks at work in my spare time, I have
> some observations:
> - Documentation should be the number one priority. I realize there is
> movement on this but I am not clear on the specifics other than Sphinx
> being mentioned, which is really good to hear.

The 2nd edition of the book is under active development right now -
Massimo's draft text is beign reviewed/enhanced by a team of other
developers.
I assure you that, just as it was 1 year ago, this will be the
authoritative reference on Web2Py once released.
Since the aim for the next phases of Web2Py is to make as few changes
as possible, then this documentation shouldn't become as limited as
quickly as the last 1 (I'd say out of date, but the last book is still
all correct & working...just that it misses out many newer
functionalities).
I really hope that the PDF version can be made freely-downloadable too
- I know Massimo is trying for this.

Meanwhile, I think that the 'New Cookbook Tutorial' is really very
good, either standalone or, for bringing the 1st edition of the book
up to date:
http://web2py.com/examples/default/docs

Like all successful projects projects which have been around, there
are bound to be snippets of information around the place on the
fringes that go out of date.
If in doubt, always check the main website & look at the official
resources as more authoritative than the community-generated ones.

F

[mdipierro]

> - Documentation should be the number one priority. I realize there is
> movement on this but I am not clear on the specifics other than Sphinx
> being mentioned, which is really good to hear.

Yes we are working on this. But mind Sphix will mostly be a replacent
to epydoc which is already there. This means better presentation but
not necessarily different content. Lots of examples are already in
epydoc and we will add more.

The old book covers almost everything but Crud, Auth, Services. These
will be described in more details in the new book. Those chapters are
already posted on the list.

> - Building out the resources for prospective web2py developers should
> take precedence over anything like CMS or eStore (though I personally

> would benefit from both of those).  Things likehttp://www.djangosnippets.org/

> for web2py would go a long way to spreading the gains from any/all
> projects around to the larger community.  Something like Railscasts
> would also be a good example of something that could be both a project
> and service to newcomers.

I would love this but I do not have the resources to run it and
maintain it. If anybody wants to help and create a site like that I
will be happy to link it. Not everything needs to be centralized. The
more decentralized the better.

> I think the idea of cleaning up the appliance app is a good idea and
> inline with the above.

Once more. I ONLY focus on web2py code libraries. I post my proof of
concepts apps on appliances. I also post appliances that people send
it. I really really encourage people to adopt some of those apps and
become mantaners. In an ideal world appliances would link applications
stores somewhere else.

Lots of people ask me to put more stuff on my site. I ask you the
opposite: help me take stuff off of it. Take charge of a part of it. I
will like your site.

> I am still trying to make myself fluent with web2py and even though it
> is a lot simpler to pick up than Django, for example, I felt a lot
> more secure in the Djangoverse because of the kick-ass documentation
> and community support.  Whatever else you want to say about the Django
> folks, they are definitely organized and they serve up some nice
> things to their community.

Yes they are organized.

> A laundry list of complaints would sound like nitpicking but little
> things can really annoy... like when i am copying/pasting code form
> the how-to section of the web page and all of the string quotes come
> over like `some string` so I have to manually edit every string I just
> pasted.

yes we need to fix that.

Massimo

[gluegl]

Please count on me to deliver the WebDesign ELEMENTS....
Will send you a sample later tonight....
G