[web2py] Re: RFC on component trap form, serialize also the button used to submit the form

Good catch Anthony. My test submit button did not have a name. On Saturday, November 8, 2014 11:32:09 AM UTC-5, Anthony wrote: > > In web2py.js, we have: > > formInputClickSelector: 'input[type=submit]:not([name]), > input[type=image]:not([name]), button[type=submit]:not([name]), > button:

[web2py] Re: RFC on component trap form, serialize also the button used to submit the form

PR in, with updates to the current situation. -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the

[web2py] Re: RFC on component trap form, serialize also the button used to submit the form

my bad. I was working on an app that had an old web2py.js. seems definitely some bad idea to exclude buttons with no name. On Saturday, November 8, 2014 5:32:09 PM UTC+1, Anthony wrote: > > In web2py.js, we have: > > formInputClickSelector: 'input[type=submit]:not([name]), > input[type=imag

[web2py] Re: RFC on component trap form, serialize also the button used to submit the form

In web2py.js, we have: formInputClickSelector: 'input[type=submit]:not([name]), input[type=image]:not([name]), button[type=submit]:not([name]), button:not([type]):not([name])' Doesn't that only select buttons with no names? But in this case, we specifically want to capture buttons with nam

[web2py] Re: RFC on component trap form, serialize also the button used to submit the form

we're talking about something that goes on only on click. I feel more "safe" knowing that if some weird things are going on with either the name or the value, it'll be handled by jquery "serialize()", as any other field. Performance-wise, it's something that happens client-side, so no worries.

[web2py] Re: RFC on component trap form, serialize also the button used to submit the form

LOL That seems to work too. Would it be more efficient to add the hidden field than appending to the serialized string with the 2 calls to encodeURIComponent ?. In any case I will get the info I need. Thanks Niphlod. On Friday, November 7, 2014 6:26:50 PM UTC-5, Niphlod wrote: > > grrr... exc

[web2py] Re: RFC on component trap form, serialize also the button used to submit the form

ah shoot, submit can also be triggered pressing "enter"... guess we're stuck with this then.. opinions ? (if everybody agrees I'll send a PR) trap_form: function (action, target) { /* traps any LOADed form */ $('#' + target + ' form').each(function (i) { var form = $(this)

[web2py] Re: RFC on component trap form, serialize also the button used to submit the form

On Friday, November 7, 2014 4:44:51 PM UTC-5, Niphlod wrote: > > uhm, I'm really missing the server-side code to handle such a form... > could you post an example with a "real-life" implementation ? > It was suggested that this should be accomplished in the form's action (presumably by including

[web2py] Re: RFC on component trap form, serialize also the button used to submit the form

grrr... except of course the console.log line ^_^' Time to go to sleep... On Saturday, November 8, 2014 12:24:35 AM UTC+1, Niphlod wrote: > > ah shoot, submit can also be triggered pressing "enter"... > guess we're stuck with this then.. opinions ? (if everybody agrees > I'll send a PR) > > t

[web2py] Re: RFC on component trap form, serialize also the button used to submit the form

I was asking for the code handling it, but I suppose I got it you check for, e.g., request.post_vars.thebuttonname == thebuttonvalue Got also why jquery "doesn't do the smart thing". Spotted also a little error related to the disableformelement function (will send a PR to fix it) in certain

[web2py] Re: RFC on component trap form, serialize also the button used to submit the form

Thanks Anthony, that is the idea. Besides the multiple button scenario, and as explained in the initial post, the serialization should include the button name and value if one was used to submit the form, just like it happens with a non-ajax trapped submit. And it seems simpler that buttons that

[web2py] Re: RFC on component trap form, serialize also the button used to submit the form

uhm, I'm really missing the server-side code to handle such a form... could you post an example with a "real-life" implementation ? On Friday, November 7, 2014 9:38:24 PM UTC+1, Anthony wrote: > > On Friday, November 7, 2014 2:23:02 PM UTC-5, Leonel Câmara wrote: >> >> You can just use a hidden

[web2py] Re: RFC on component trap form, serialize also the button used to submit the form

On Friday, November 7, 2014 2:23:02 PM UTC-5, Leonel Câmara wrote: > > You can just use a hidden field, like formname, or event better you can > have different actions for the forms. As for the code, I don't like that > this is triggered for all clicks in the form, maybe form.on('click', > '[typ

[web2py] Re: RFC on component trap form, serialize also the button used to submit the form

Thank you for your comments Leonel. I agree with the triggering and the more general URI encoding. Not sure what you mean by using a hidden field, all the buttons belong to the same form, they just have different names and values. The code has been updated as follows (relative to the original pos

[web2py] Re: RFC on component trap form, serialize also the button used to submit the form

You can just use a hidden field, like formname, or event better you can have different actions for the forms. As for the code, I don't like that this is triggered for all clicks in the form, maybe form.on('click', '[type="submit"]', You also need to encodeURI the submit button's name and

[web2py] Re: RFC on component trap form, serialize also the button used to submit the form

Seems reasonable. Anthony On Friday, November 7, 2014 1:16:18 PM UTC-5, DenesL wrote: > > Hi all, > > a bit of background on this RFC: > > Any form inside a component that has ajax=True, i.e. a form inside a > LOAD(..., ajax=True) component, > will be trapped and only the fields are serialized.

Re: [web2py] Re: RFC: web2py-based workflow engine

On Friday, April 18, 2014 8:17:54 PM UTC-7, Andrew W wrote: > > Thanks. That's a .net solution so not quite the web2py solution I was > looking for. > A quick look didn't turn up anything about workflows by Ross outside of this thread. BTW, my thoughts on a multiperson-signoff that would be

Re: [web2py] Re: RFC: web2py-based workflow engine

Thanks. That's a .net solution so not quite the web2py solution I was looking for. -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this mes

Re: [web2py] Re: RFC: web2py-based workflow engine

> > check out cDevWorkflow at > http://www.cDevWorkflow.com > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received

[web2py] Re: RFC: validator IS_NOT_IN_SET

I think this is a useful validator, any chance this can end up in web2py? On Friday, August 9, 2013 4:13:30 PM UTC-4, Kyle Flanagan wrote: > > I had to use this today. However, this does not work correctly when the > set is empty. We assume that if the set is empty, whatever variable value > bei

[web2py] Re: RFC: imapadapter api change

*To Alan E.* *Q»* Will it break *backward compatibility*, then? That will be bad. Please implement the new feature in such a way that Emails can be retrieved easily by *Message.Content[i]* for plaintext and html. And * Message.Attachments[ii]* and *Message.Attachments[ii].type* for att

[web2py] Re: RFC: imapadapter api change

> > >- Does this mean that *message.content* will not work in the future? > > This is because the current adapter uses an invalid field type for attachment and content fields that can raise errors when used with other core features. In order to keep those fields, they should have custom fi

[web2py] Re: RFC: imapadapter api change

""The content and attachment fields would be no longer available. Users have to implement their custom app code to fetch each part inspecting the complete message structure"" - Does this mean that *message.content* will not work in the future? - Also, does it mean than the users wi

[web2py] Re: RFC: validator IS_NOT_IN_SET

I had to use this today. However, this does not work correctly when the set is empty. We assume that if the set is empty, whatever variable value being tested is not in the set. Here's an updated __call__ function: def __call__(self, value): value, error = IS_IN_SET.__call__(self,

Re: [web2py] Re: RFC: web2py-based workflow engine

Does anyone know if there has been any progress on this ? Hello Ross ? On Tuesday, September 25, 2012 1:52:46 AM UTC+12, Ramos wrote: > > Same question here > Ross, > How's the workflow engine going ? > > Cheers > António > > 2012/7/6 Andrew > > >> Hi Ross, >> How's the workflow engine going ?

Re: [web2py] Re: RFC: web2py-based workflow engine

Same question here Ross, How's the workflow engine going ? Cheers António 2012/7/6 Andrew > Hi Ross, > How's the workflow engine going ? > > Regards > Andrew W > --

Re: [web2py] Re: RFC: web2py-based workflow engine

Hi Ross, How's the workflow engine going ? Regards Andrew W

Re: [web2py] Re: RFC: web2py-based workflow engine

Thanks Ross, I think it does, at least enough to give it a go.

Re: [web2py] Re: RFC: web2py-based workflow engine

No, it is just a singleton module, just like Auth or Cache.

Re: [web2py] Re: RFC: web2py-based workflow engine

Ross, Does this mean your workflow engine is also a background task? Something like my_queue = [] def handle_it(it): blah... while True: my_queue.extend(db.q_table while my_queue: mytask = my_queue.pop() handle_it(mytask) On Friday, May 25, 2012 9:31:33 AM UTC-4, Ross Peo

Re: [web2py] Re: RFC: web2py-based workflow engine

Andrew, If I'm understanding you properly, the only major difference between the business process workflow (the one I am writing) and the data integration workflow you mention is that one requires human interaction, while the other is handled by automated systems. Is that fairly accurate? If so

Re: [web2py] Re: RFC: web2py-based workflow engine

Hi Ross, The term Workflow can potentially mean a lot of things to different people, and it certainly sounds like you're talking about business process workflows. I have been looking at (well, thinking mainly) about "workflows" in the context of Data Integration applications, where there are ma

Re: [web2py] Re: RFC: web2py-based workflow engine

+1 On Thursday, 24 May 2012 14:57:55 UTC-5, Richard wrote: > > Keep going Ross, I like what I read! > > :) > > Richard > > On Thu, May 24, 2012 at 3:29 PM, Ross Peoples wrote: > >> Just wanted to give an update on this. I'm working on the workflow engine >> nearly every day. Workflow engines are

Re: [web2py] Re: RFC: web2py-based workflow engine

Keep going Ross, I like what I read! :) Richard On Thu, May 24, 2012 at 3:29 PM, Ross Peoples wrote: > Just wanted to give an update on this. I'm working on the workflow engine > nearly every day. Workflow engines are complicated things with lots of > pitfalls that need to be taken into account

[web2py] Re: RFC: web2py-based workflow engine

Just wanted to give an update on this. I'm working on the workflow engine nearly every day. Workflow engines are complicated things with lots of pitfalls that need to be taken into account. Having said that, I am getting closer to completing it. What works: - Templates - Creating workflo

[web2py] Re: RFC: web2py-based workflow engine

I took a quick look at the site. ISTM the commonality in all the workflows is that each task in the workflow has defined entry and exit criteria. Right now I'm implementing human-provided criteria. Most of the workflows at workflowpatterns.com include non-human system events in the criteria.

[web2py] Re: RFC: web2py-based workflow engine

Yes, thanks for the links. I was able to add parallel steps that work as you describe. I have almost finished my workflow engine. I only have a couple more methods to write before I begin writing unit tests. Thanks for all the input. I am still taking comments and suggestions, so if anyone has

[web2py] Re: RFC: web2py-based workflow engine

Derek, Thanks for the links. My model handles parallel flows through the state links table. On Thursday, May 17, 2012 6:42:27 PM UTC-4, Derek wrote: > > I think you are just using abstract examples, though workflows are more > than just creating a widget or approving invoices. > The standard fo

[web2py] Re: RFC: web2py-based workflow engine

I think you are just using abstract examples, though workflows are more than just creating a widget or approving invoices. The standard for workflow support is here: http://www.workflowpatterns.com/ (look here for a tidy list of workflow types... http://www.workflowpatterns.com/evaluations/ope

[web2py] Re: RFC: web2py-based workflow engine

On Thursday, May 17, 2012 3:54:44 PM UTC-4, Cliff wrote: > > Let's inject manufacturing into the order processing scenario you were > using before. It's a three step process. Step one fabricates widgets. > Step 2 attaches the widgets to widget bicarackets, purchased from another > vendor.

[web2py] Re: RFC: web2py-based workflow engine

Let's inject manufacturing into the order processing scenario you were using before. It's a three step process. Step one fabricates widgets. Step 2 attaches the widgets to widget bicarackets, purchased from another vendor. Step 3 packages the assemblies for shipment. If the last batch of wi

[web2py] Re: RFC: web2py-based workflow engine

On Thursday, May 17, 2012 9:37:46 AM UTC-4, Cliff wrote: > > Ross, > > I understand your reasons for attaching approvals to the workflow. I do > it the other way because if a deliverable needs approval by six parties, > putting six additional steps in the flow makes things a little cluttered.

[web2py] Re: RFC: web2py-based workflow engine

Ross, I understand your reasons for attaching approvals to the workflow. I do it the other way because if a deliverable needs approval by six parties, putting six additional steps in the flow makes things a little cluttered. If you add six people as performers of an approval step, does that m

[web2py] Re: RFC: web2py-based workflow engine

The data model I already have does things a bit differently, but I think it accomplishes the same thing. I am in the process of writing all of the support methods. This is my current data model: # workflow table db.define_table('workflow', Field('name', length=50), Field('is_template',

[web2py] Re: RFC: web2py-based workflow engine

Ross, I like the workflow monitor table, though I think it should be tied to the template rather than individual workflows. Since each stage knows the id of its parent workflow and the workflow knows the id of its template, it would be a simple matter to get the monitors and ping them when the

[web2py] Re: RFC: web2py-based workflow engine

Cliff, Thanks for putting this into a spec. My current code follows most of what is in there. I still haven't finished writing (or testing it), but I do have some thoughts on implementation for one or two of the items listed at the end: I imagine a "workflow_monitor" table that has the fields:

[web2py] Re: RFC: web2py-based workflow engine

I have collected my thoughts into a specification, available at this link . Comments invited and welcome. Thank you. On Tuesday, May 1, 2012 12:00:42 PM UTC-4, Ross Peoples wrote: > > In reference to: >

[web2py] Re: RFC: web2py-based workflow engine

Ross, This comes at an opportune time, as I have been asked to do some workflow work. Here's where you need authorization. This scenario has two players, a department manager and the company accountant. An invoice comes to the department manager, so at that point we might call its state rec

Re: [web2py] Re: RFC: web2py-based workflow engine

Hi, Ross, I think that the entire community is thinking and walking in the RIGHT way. And your effort is a prove of this. Congratulations. So, IMHO, I think that workflows are not only linear, but in some cases we have concurrent tasks to do. If your algorithm is compliant with this, I think that

Re: [web2py] Re: RFC: web2py-based workflow engine

Please see my workflow framework in Lotus Notes, in the end of creating rules, i use graphviz to draw the graph of the workflow.. http://www.youtube.com/watch?v=zMNwqAtiFOw Also i manage centrally all rules and all apps point to my framework like a workflow as a service. Easier to manage. i think

[web2py] Re: RFC: web2py-based workflow engine

Cliff, Thanks for the feedback. I added the ability to name / title steps. I also added the ability to set priorities for workflows. It is assumed that when a step is complete, that step is already "done" and the next step in workflow is "new". Each step has an order_id to show which order the

[web2py] Re: RFC: web2py-based workflow engine

Ross, I like the on-the-fly ability. Each step in your template changes the state of the item. Each one of those states should have a title. There are two other states to account for, new and done. Workflows sometimes have more than one path to completion. I see an entity called a workflow

[web2py] Re: RFC: New design for {{include file.html}} in views

Yes this is a much better design pattern. I will just make a file of these helpers and include them all at once. Thanks massimo! On Sep 9, 10:32 pm, Massimo Di Pierro wrote: > Why not do: > > in friend_selector.html > > {{def selector(id=None):}} >                 >                         >

[web2py] Re: RFC: New design for {{include file.html}} in views

Why not do: in friend_selector.html {{def selector(id=None):}} {{return}} and in the extending view {{include 'friend_selector.html'}} {{selector(id='main-access')}} This is already supported and allows to defin

[web2py] Re: RFC about issue

+1 On Aug 11, 6:24 am, Massimo Di Pierro wrote: > What do people think? > > http://code.google.com/p/web2py/issues/detail?id=370 > > I do not have a strong opinion.

[web2py] Re: RFC about issue

My only concern is that with rounded corner buttons the E of Edit may touch the corner, unless the buttons are taller or wider. The e of edit does not suffer this problem. On Aug 11, 5:56 pm, Michael Toomim wrote: > I agree not a big > deal:http://www.quora.com/Should-buttons-in-web-apps-be-capi

[web2py] Re: RFC about issue

I agree not a big deal: http://www.quora.com/Should-buttons-in-web-apps-be-capitalized On Aug 11, 3:24 am, Massimo Di Pierro wrote: > What do people think? > > http://code.google.com/p/web2py/issues/detail?id=370 > > I do not have a strong opinion.

[web2py] Re: RFC about issue

+1, and it's not that big deal anyway

Re: [web2py] Re: RFC about issue

+1

Re: [web2py] Re: RFC about issue

+1 I'm doing this, to display for example error messages using css. div.error { text-transform:capitalize; } 2011/8/11 Anthony > +1 > > On Thursday, August 11, 2011 6:24:30 AM UTC-4, Massimo Di Pierro wrote: > >> What do people think? >> >> http://code.google.com/p/**web2py/issues/detai

[web2py] Re: RFC about issue

+1 On Thursday, August 11, 2011 6:24:30 AM UTC-4, Massimo Di Pierro wrote: > What do people think? > > http://code.google.com/p/web2py/issues/detail?id=370 > > I do not have a strong opinion.

[web2py] Re: RFC: validator IS_NOT_IN_SET

Do validators have an opposite such as "not IS_IN_SET()"?

[web2py] Re: RFC: validator IS_NOT_IN_SET

I was looking for IS_NOT_IN_SET today and found this. Thanks.

Re: [web2py] Re: RFC: new URL routing facility

On Jan 2, 2011, at 8:19 AM, villas wrote: > > Hi Jonathan > If the framework had such a variable I would use it. But it's a tiny > issue so please don't let me further distract you from the other > enhancements you are planning :-) It'll be (almost) trivial to add it. I'll put it on my todo list.

[web2py] Re: RFC: new URL routing facility

Hi Jonathan If the framework had such a variable I would use it. But it's a tiny issue so please don't let me further distract you from the other enhancements you are planning :-) Thanks. D On Jan 2, 3:58 pm, Jonathan Lundell wrote: > On Jan 2, 2011, at 5:54 AM, villas wrote: > > > > > Well, say

Re: [web2py] Re: RFC: new URL routing facility

On Jan 2, 2011, at 5:54 AM, villas wrote: > > Well, say I make a plugin which I want to link back to a function in > my default_controller. I would not wish to to make my link like this > URL('default','func'), but like this URL(default_controller,'func'). > See what I mean? Sort of. The problem

[web2py] Re: RFC: new URL routing facility

Well, say I make a plugin which I want to link back to a function in my default_controller. I would not wish to to make my link like this URL('default','func'), but like this URL(default_controller,'func'). See what I mean? On Jan 2, 2:09 am, Jonathan Lundell wrote: > On Jan 1, 2011, at 5:46 PM,

Re: [web2py] Re: RFC: new URL routing facility

On Jan 1, 2011, at 5:46 PM, villas wrote: > > The 'default_controller' variable in routes.py doesn't seem to be > available in the rest of the app. > From where may I access that information? > Or, do I have to set that variable again in as an app setting > somewhere (not very DRY!). I'm not sure

[web2py] Re: RFC: new URL routing facility

Hi Jonathan The 'default_controller' variable in routes.py doesn't seem to be available in the rest of the app. >From where may I access that information? Or, do I have to set that variable again in as an app setting somewhere (not very DRY!). -David

Re: [web2py] Re: RFC: new URL routing facility

On Jan 1, 2011, at 9:25 AM, Arun K.Rajeevan wrote: > When will it be available for us to experiment. > > regex is always a bit difficult to maintain. I hope to get a beta patch to Massimo in a few days. By "beta" I mean that it's not fully tested, and the API might not be final. But all the fu

[web2py] Re: RFC: new URL routing facility

When will it be available for us to experiment. regex is always a bit difficult to maintain.

[web2py] Re: RFC: new URL routing facility

I especially like the language support which will enable consistent bookmarking of urls. This all seems very good - thanks! -D On Dec 31 2010, 10:36 pm, Jonathan Lundell wrote: > I've been working on a new URL routing facility that provides fairly powerful > rewriting with very simple configurat

Re: [web2py] Re: RFC: Why web2py rocks

On Tue, Nov 9, 2010 at 1:44 PM, Bruno Rocha wrote: > I just need to find out how to edit .svg in a Mac. I'll try InkScape for > Mac/X11 It's an Inkscape SVG, so Inkscape would be your best bet. Just so you know, line wrapping is manual (that's how I did it, that is). -- Branko Vukelić bg.bra

Re: [web2py] Re: RFC: Why web2py rocks

On Tue, Nov 9, 2010 at 3:04 PM, Branko Vukelic wrote: > On Tue, Nov 9, 2010 at 1:44 PM, Bruno Rocha wrote: >> I just need to find out how to edit .svg in a Mac. I'll try InkScape for >> Mac/X11 > > It's an Inkscape SVG, so Inkscape would be your best bet. Just so you > know, line wrapping is manu

Re: [web2py] Re: RFC: Why web2py rocks

I am working on Inkscape for Mac! very nice!, I should never open coreldraw or Illustrator anymore. Thank you! 2010/11/9 Branko Vukelic > On Tue, Nov 9, 2010 at 3:04 PM, Branko Vukelic > wrote: > > On Tue, Nov 9, 2010 at 1:44 PM, Bruno Rocha > wrote: > >> I just need to find out how to edit .

Re: [web2py] Re: RFC: Why web2py rocks

I just need to find out how to edit .svg in a Mac. I'll try InkScape for Mac/X11 2010/11/9 Branko Vukelic > On Tue, Nov 9, 2010 at 2:54 AM, Bruno Rocha wrote: > > Branko, I want to have a portuguese version, do you mind if I edit the > file > > translating into portuguese? > > Sure, Bruno. Here

[web2py] Re: RFC: Why web2py rocks

On Nov 9, 12:16 am, mdipierro wrote: > This is not the first image I have seen this this format (thin and > long) but I am not sure I understand what it is intended for. Beauty. DeviantArt has a great many like this for Photoshop tutorials, for example.

[web2py] Re: RFC: Why web2py rocks

Looks great. Nice work. On Nov 8, 5:53 pm, Branko Vukelic wrote: > On Mon, Nov 8, 2010 at 11:47 PM, Anthony wrote: > > Also, "From the day one" not fixed yet. > > Ok, all fixed. I think... :P Thanks for help. > > Here's the JPG version. > > -- > Branko Vukelić > > bg.bra...@gmail.com > stu...@br

Re: [web2py] Re: RFC: Why web2py rocks

Branko, I want to have a portuguese version, do you mind if I edit the file translating into portuguese? 2010/11/8 Branko Vukelic > On Mon, Nov 8, 2010 at 11:47 PM, Anthony wrote: > > Also, "From the day one" not fixed yet. > > Ok, all fixed. I think... :P Thanks for help. > > Here's the JPG ve

[web2py] Re: RFC: Why web2py rocks

Also, "From the day one" not fixed yet. On Nov 8, 5:44 pm, Branko Vukelic wrote: > Oh rats. Attached the wrong version w/p RPC fixed. :P > > > > > > On Mon, Nov 8, 2010 at 11:42 PM, Branko Vukelic wrote: > > Here's the corrected version. Let me know if you spot anything else. > > > -- > > Branko

Re: [web2py] Re: RFC: Why web2py rocks

Oh rats. Attached the wrong version w/p RPC fixed. :P On Mon, Nov 8, 2010 at 11:42 PM, Branko Vukelic wrote: > Here's the corrected version. Let me know if you spot anything else. > > -- > Branko Vukelić > > bg.bra...@gmail.com > stu...@brankovukelic.com > > Check out my blog: http://www.brankovu

Re: [web2py] Re: RFC: Why web2py rocks

On Mon, Nov 8, 2010 at 10:19 PM, Stefaan Himpe wrote: > (Btw I like the gray background - it occurred to me that perhaps a similar > background might also look good in the admin app, which now looks a bit > "white" to my eyes.) Massimo is partial to white, so I kept it. Personally, I never go hig

Re: [web2py] Re: RFC: Why web2py rocks

On Mon, Nov 8, 2010 at 11:16 PM, mdipierro wrote: > I would remove the sentence "if you skip... you only have 50 objects > to learn". Ok. > This is not the first image I have seen this this format (thin and > long) but I am not sure I understand what it is intended for. For vertical scrolling.

Re: [web2py] Re: RFC: Why web2py rocks

On Mon, Nov 8, 2010 at 10:46 PM, Anthony wrote: > Yes, "Maybe not as web2py" should be "Maybe not as paranoid as web2py" > or just "Maybe not as much as web2py". > > A few other typos: > - Should be "31 validators" (i.e., plural) > - "named after the HTML elements they represent" (i.e., add "the")

[web2py] Re: RFC: Why web2py rocks

I would remove the sentence "if you skip... you only have 50 objects to learn". This is not the first image I have seen this this format (thin and long) but I am not sure I understand what it is intended for. Massimo On Nov 8, 2:43 pm, Branko Vukelic wrote: > Here's the update. I did not includ

[web2py] Re: RFC: Why web2py rocks

Yes, "Maybe not as web2py" should be "Maybe not as paranoid as web2py" or just "Maybe not as much as web2py". A few other typos: - Should be "31 validators" (i.e., plural) - "named after the HTML elements they represent" (i.e., add "the") - "first applications written for the web2py framework" (i.

[web2py] Re: RFC: Why web2py rocks

Hope you enjoy it. If you guys think it's OK as it is, I'll post a PDF version somewhere. I spotted a typo "alaready" (from: The age of web applications has alaready started...and web2py is there) The sentence "Maybe not as web2py." sounds a bit weird to me (but I'm not a native English sp

Re: [web2py] Re: RFC: Why web2py rocks

Thanks everyone for the input. I'll revise, and then post it here tonite. :) On Mon, Nov 8, 2010 at 4:44 AM, Anthony wrote: > Very cool, Branko. And good suggestions, Bruno, especially mentioning > the community and great support. > > A few other distinctives: > - web2py is built for security > -

[web2py] Re: RFC: Why web2py rocks

Very cool, Branko. And good suggestions, Bruno, especially mentioning the community and great support. A few other distinctives: - web2py is built for security - very active development - constant stream of enhancements/ improvements - plugin_wiki Regarding Rocket, although I suppose it is "produ

[web2py] Re: RFC: Why web2py rocks

Theres a typo in full-stack section its says "pick trhough" instead "pick through" great jobs anyways!

[web2py] Re: RFC: Why web2py rocks

I forgot URL and XML which technically are a helpers. So request response session cache T redirect DAL Field SQLFORM SQLTABLE XML URL adds up to 12. On Nov 7, 8:37 pm, mdipierro wrote: > I really like. About the 80 objects to get started. > > I just counted them again. I would say 13 objects +

[web2py] Re: RFC: Why web2py rocks

I really like. About the 80 objects to get started. I just counted them again. I would say 13 objects + 31 validators + 60 helpers (which map 1-1 to HTML tags) + 3 tools (Auth, Crud, Service). The 13 objects are request response session cache T redirect DAL Field SQLFORM SQLTABLE LOAD local_imp

Re: [web2py] Re: RFC

On Sun, Nov 7, 2010 at 3:10 PM, mr.freeze wrote: > I totally agree Kevin. From the Zen of Python: "There should be one-- > and preferably only one --obvious way to do it." Zen of Python is best for quoting. I don't know any Python developer that hasn't broken at least one of the commandments (and

[web2py] Re: RFC

I totally agree Kevin. From the Zen of Python: "There should be one-- and preferably only one --obvious way to do it." On Nov 6, 8:15 pm, Kevin wrote: > Systems get harder to learn when there are seemingly multiple ways to > do things.  It's not always clear that alternatives are really > optiona

[web2py] Re: RFC

Systems get harder to learn when there are seemingly multiple ways to do things. It's not always clear that alternatives are really optional, or if different parameter conventions are needed in different situations. I had a little trouble learning parts of the DAL, for example, when it's not clea

Re: [web2py] Re: RFC

On Sun, Nov 7, 2010 at 12:00 AM, Mariano Reingart wrote: > Indeed, for wizard I would prefer more explicit dropdown fields, that > would be more intuitive to begginers. I +1 this. It's not easy to guess what you can write in those fields for sure. -- Branko Vukelić bg.bra...@gmail.com stu...@b

Re: [web2py] Re: RFC

I don't think it's a good idea to add that to web2py core because: * It introduces a new free-form table definition that we'll have to honor for backward compatibility forever * It breaks too much forward compatibility (forcing unknown version updates for new field "types" like wiki) * it could no

[web2py] Re: RFC

You could mix but not this way. db.define_table('person','name unique, address, married boolean, bio wiki') db.person.bio.default='...' On Nov 5, 10:04 pm, rochacbruno wrote: > bio wiki will be a Markmin represent? > > I think it is a good idea, but , if mixed with the normal sintax, will it >

Re: [web2py] Re: RFC @completion

http://code.google.com/p/blogitizor/source/browse/src/models/plugin_compression.py -Thadeus On Tue, Jan 26, 2010 at 7:17 PM, hamdy.a.farag wrote: > > Thanks Thadeus for replying > > I didn't understand though, because this concept is new for me > > can you please give me examples ? > > -- > Y

[web2py] Re: RFC @completion

Thanks Thadeus for replying I didn't understand though, because this concept is new for me can you please give me examples ? -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web...@googlegroups.com. To unsu

  1   2   >