Model validation
rihad
validation? Like, min/max value/length a numerical/textual value may
have. On the same note, how come there's no support for HTML forms? A
form thing which would preferably grab fields from a model to avoid
duplicating stuff. Or are we talking lightweight here? :)
Benjamin Sims
I have used Deform (http://docs.pylonsproject.org/projects/deform/en/latest/) for form generation, which in turn uses Colander for validation. Have a look at:
http://deformdemo.repoze.org/
for a demo of capabilities
There is also a package, pyramid_formalchemy (http://docs.formalchemy.org/pyramid_formalchemy) which will do CRUD based on SQLAlchemy models, but I haven't used it personally.
Ben
--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-...@googlegroups.com.
To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Chris McDonough
> Hi, all. Does Pyramid (or Sqlalchemy) offer any kind of model
> validation? Like, min/max value/length a numerical/textual value may
> have.
I use Colander for this:
http://docs.pylonsproject.org/projects/colander/en/latest/
Folks also use FormEncode.
> On the same note, how come there's no support for HTML forms? A
> form thing which would preferably grab fields from a model to avoid
> duplicating stuff. Or are we talking lightweight here? :)
There's Deform: http://docs.pylonsproject.org/projects/deform/en/latest/
(which uses Colander) or dozens of other form libraries (Formish,
WTForm, ToscaWidgets, pyramid_simpleform, the list goes on...)
Pyramid has no canonical notion of "model", so that's not really a
Pyramid thing. But pyramid_formalchemy can create forms from SQLAlchemy
models.
- C
Chris Rossi
While, still pretty experimental and not considered stable (from the
standpoint of the API being fixed, it does work just fine) limone
provides a way to have validation directly on the models themselves.
It uses Colander schemas. Effectively, it takes a Colander schema as
an input and spits out a class which enforces the schema on instances
of that class:
https://github.com/Pylons/limone
Chris
rihad
rihad
makes using Pyramid a bit confusing at first. It's like needing to get
separate Firefox plugins to enable JavaScript, show JPEGs, browse FTP
sites, handle form submission, etc. Dare I say, I find full-stack
frameworks like TG2 more... appealing. Perhaps lightweight frameworks
such as Pyramid are for more advanced usage, although I doubt for
which purpose, given that problems a web programmer faces in his
projects are amazingly the same. In other words, everyone is welcome
to build their own magic framework out of Pyramid as they see fit.
That's not a bad thing at all, if that's what you want :)
Alan Runyan
Alan Runyan
Office +17135305244 | Skype/Twitter @runyaga
President of Enfold Systems | http://www.enfoldsystems.com/
Co-founder of the Plone CMS | Free Plone site in less than 10 seconds - http://ploud.com/
Chris McDonough
> Pfff... I've got a confession to make :) All this "lightweightedness "
> makes using Pyramid a bit confusing at first. It's like needing to get
> separate Firefox plugins to enable JavaScript, show JPEGs, browse FTP
> sites, handle form submission, etc. Dare I say, I find full-stack
> frameworks like TG2 more... appealing.
I sympathize with this sentiment, because of course everyone wants it to
be as easy as possible and everyone hates making choices.
> Perhaps lightweight frameworks
> such as Pyramid are for more advanced usage, although I doubt for
> which purpose, given that problems a web programmer faces in his
> projects are amazingly the same. In other words, everyone is welcome
> to build their own magic framework out of Pyramid as they see fit.
> That's not a bad thing at all, if that's what you want :)
I've been doing this a long time now. I've seen hundreds of people
spend tens of thousands of hours on code, building huge monothic systems
that are eventually crushed under their own weight. I've seen them try
to slim down their stack in the face of impossible backwards
compatibility concerns. I've seen them try to unmake overeager choices
that were made a decade ago, and only succeed at annoying existing
users. I've seen people try to use these systems in ways they weren't
intended to be used, and build horrifying contraptions to work around
baked-in design constraints. I've seen second-generation system
maintainers not get the jokes originally assumed by the first
generation, and weld previously completely independent subsystems
together for the sake of a convenience import. I've seen reams and
reams of underdocumented and undocumented code. I've seen two people
add code to the same package that does the same thing because nobody
really knows how it works anymore. I've seen those systems lose
relevance. That's not a bad thing at all, if that's what you want.
Seriously, though, higher level things will pop up that are built with
Pyramid. ptah, apex, kotti, and khufu are such systems now, and I'm
hoping they'll please the full-stack-wanting crowd. If not, then, well,
there are certainly no shortage of Python framework choices, as
frightening as some of them are.
- C
Thomas G. Willis
Thomas G. Willis
Vlad K.
No they're not the same. I'm developing a complex app based on Pyramid
and I love the fact that Pyramid is lightweight and not assuming things.
It allows me to:
1. choose peppercorn + colander to validate multilevel forms (forms that
are not flat key-value pairs but complex hierarchies), instead some flat
key-value form validation which I'd have to work around to implement this
2. reuse same colander schemes to validate model data coming from or to
channels other than POST (like daily XML and CVS imports / exports)
instead of duplicate work or have to work around and simulate POST if I
wanted to reuse the validation scheme
3. use my own authn/authz schemes to implement pure AJAX client
authentication, and while at it choose whatever persistence model I want
4. use SQLAlchemy for ORM and not some in-house concoction
5. use Mako templating or any other templating system, I just love Mako
6. write maintenance and command line scripts that bootstrap the
application so I can reuse its facilities without having to duplicate code
.oO V Oo.
Michael Bayer
On Dec 12, 2011, at 2:40 PM, Chris McDonough wrote:
> I've seen two people
> add code to the same package that does the same thing because nobody
> really knows how it works anymore.
This reads like the argument people make for off-the-shelf/out-of-the-box, rather than against it. Unless you mean, they had to write a bunch of spaghetti to work around the limitations of the package.
Chris McDonough
It just means that the code is so convoluted, or the existing maintainer
base so far removed from an older one, or the codebase so poorly
documented that newer people don't even understand the intent of the
code anymore, and can't even recognize that they're doing something that
has already been done.
- C
Mike Orr
> Pfff... I've got a confession to make :) All this "lightweightedness "
> makes using Pyramid a bit confusing at first. It's like needing to get
> separate Firefox plugins to enable JavaScript, show JPEGs, browse FTP
> sites, handle form submission, etc. Dare I say, I find full-stack
> frameworks like TG2 more... appealing.
The TurboGears folks were going to build a TG-like framework on top of
Pyramid... but I have not heard anything about it for several months
so it may be inactive.
Ptah aims to offer the same kind of bells and whistles Django does.
It's at an initial alpha release. It's the closest Pyramid has to a
full-stack framework right now.
Kotti is specifically a content-management system.
I haven't looked at Khufu recently so I'm not sure how much it contains.
> Perhaps lightweight frameworks
> such as Pyramid are for more advanced usage, although I doubt for
> which purpose, given that problems a web programmer faces in his
> projects are amazingly the same. In other words, everyone is welcome
> to build their own magic framework out of Pyramid as they see fit.
> That's not a bad thing at all, if that's what you want :)
That's why Pyramid is the way it is. It's a mid-level framework like
Pylons. Pyramid is a mid-level framework like Pylons. For a
lightweight framework, see web.py, Aspen, Quixote, Flask, Werkzeug, or
several others. Pyramid's focus is on being scalable, both down and
up. You can make a Pyramid application and launcher in a single script
file. Or you can build an elaborate full-stack framework on top of
Pyramid, or use an off-the-shelf one. With Pyramid there are multiple
ways to do it, but they are all interoperable. Our goal is not to
force everyone to a mid-level framework, but to provide such good
building blocks that future high-level frameworks choose Pyramid as a
foundation.
--
Mike Orr <slugg...@gmail.com>
rihad
On Dec 13, 6:55 am, Mike Orr <sluggos...@gmail.com> wrote:
> Pyramid is a mid-level framework like Pylons. For a
> lightweight framework, see web.py, Aspen, Quixote, Flask, Werkzeug, or
> several others. Pyramid's focus is on being scalable, both down and
> up. You can make a Pyramid application and launcher in a single script
> file. Or you can build an elaborate full-stack framework on top of
> Pyramid, or use an off-the-shelf one. With Pyramid there are multiple
> ways to do it, but they are all interoperable. Our goal is not to
> force everyone to a mid-level framework, but to provide such good
> building blocks that future high-level frameworks choose Pyramid as a
> foundation.
>
> --
So it's a perfect tool for writing a framework :)
Lightweight in my understanding means few features, mostly glue code.
Just like Pyramid. All other meaty, but nonetheless important
features, are meant to be chosen by a developer using that framework,
and plugged in. For example, AFAIK Pyramid has no Form/validation
subsystem in its core, or even an "official" plug-in that it endorses.
Through trial and error, you have to just pick the missing part from
the plethora of what's available, that would suit you functionally and
esthetically. Maybe in the long run this would make you a more savvy,
professional developer. But you'll have to agree with me, that if our
goal is to build bigger, less buggy programs, we're gonna have to
abstract from smaller details, use bigger bricks, so to speak. That's
why people have chosen C, not assembly to write most parts of a larger
OS; PHP, Perl or Python over C for web work, Frameworks over plain
PHP, Perl or Python to facilitate building even larger programs. And
that's because a human, however smart he or she is, cannot hold all
the miniscule details in his head. People can see the bigger picture
more clearly. So unless there's a larger framework built on top of
Pyramid, as it is now the learning curve of getting the needed tools
and do some CRUD/DB/auth/form edit/add, lists/pagination with some
custom functionality - is pretty slow.
Chris McDonough
>
> On Dec 13, 6:55 am, Mike Orr <sluggos...@gmail.com> wrote:
> > Pyramid is a mid-level framework like Pylons. For a
> > lightweight framework, see web.py, Aspen, Quixote, Flask, Werkzeug, or
> > several others. Pyramid's focus is on being scalable, both down and
> > up. You can make a Pyramid application and launcher in a single script
> > file. Or you can build an elaborate full-stack framework on top of
> > Pyramid, or use an off-the-shelf one. With Pyramid there are multiple
> > ways to do it, but they are all interoperable. Our goal is not to
> > force everyone to a mid-level framework, but to provide such good
> > building blocks that future high-level frameworks choose Pyramid as a
> > foundation.
> >
> > --
> So it's a perfect tool for writing a framework :)
> Lightweight in my understanding means few features, mostly glue code.
> Just like Pyramid. All other meaty, but nonetheless important
> features, are meant to be chosen by a developer using that framework,
> and plugged in. For example, AFAIK Pyramid has no Form/validation
> subsystem in its core, or even an "official" plug-in that it endorses.
You are presuming that there is a one true form library that does
everything well that is completely satisfactory in all cases. I can
tell you from pretty hard experience that this is not true. To the
extent that I recommend a single form library, I tend to recommend
Deform because a) I wrote it and b) it's a Pylons project. But I always
qualify my recommendation of it with "it's great for autogenerating
forms, but it's not so great if you want pixel-control over the layout".
For that, I tend to recommend pyramid_simpleform (also a Pylons
project).
These choices are not canonized in Pyramid or in its core narrative
documentation. That's because both Deform and pyramid_simpleform are
written for particular purposes, and neither is good for all use cases.
That may change in the future and there are lots of other form libraries
that might be better in any given scenario too. If you ask here or in
IRC people will help guide you in the right direction. There should
likely be more info in the Cookbook about how to make this particular
choice, and we could definitely guide people towards it better without
having to ask, but Pyramid itself won't ever make it for you.
> Through trial and error, you have to just pick the missing part from
> the plethora of what's available, that would suit you functionally and
> esthetically. Maybe in the long run this would make you a more savvy,
> professional developer. But you'll have to agree with me, that if our
> goal is to build bigger, less buggy programs, we're gonna have to
> abstract from smaller details, use bigger bricks, so to speak.
You want direction; folks who use Pyramid are happy to give it to you if
you ask. I spend lots of time trying to contextualize integrations for
people both on IRC and in documentation, and others do the same.
As far as building things using bigger blocks, I understand that people
want this very badly. Although Pyramid is not in the big-block-selling
business, someone else is always willing to sell you bigger blocks. And
that's great. The blocks don't always line up evenly with your
expectations or even sometimes with reality. And sometimes that's OK
because, let's be honest, your expectations and reality kinda sucked
anyway, and at least you can have some fun bitching about how much
building this system out of these blocks that don't fit into the holes
in your application with other folks that were also sold the same
blocks. And your application kinda sorta works and that's often good
enough.
But sometimes smaller blocks are just what the doctor ordered if you
really need it to work well, you actually know what you want to do, and
you're willing to seek consultation from trusted colleagues about how to
do it.
> That's
> why people have chosen C, not assembly to write most parts of a larger
> OS; PHP, Perl or Python over C for web work, Frameworks over plain
> PHP, Perl or Python to facilitate building even larger programs. And
> that's because a human, however smart he or she is, cannot hold all
> the miniscule details in his head. People can see the bigger picture
> more clearly.
Whew, I'm glad you're not describing something obvious in the most
condescending way possible.
> as it is now the learning curve of getting the needed tools
> and do some CRUD/DB/auth/form edit/add, lists/pagination with some
> custom functionality - is pretty slow.
And so be it. Instant gratification "look ma wow I made a Wiki without
even trying this is so cool" is not a goal of Pyramid itself. But it's
your right to believe it should be, and nobody can take that away from
you. ;-)
- C
Daniel Nouri
> Ptah aims to offer the same kind of bells and whistles Django does.
> It's at an initial alpha release. It's the closest Pyramid has to a
> full-stack framework right now.
>
> Kotti is specifically a content-management system.
Sorry for a little hijack. But Kotti aims really to be the kind of
bastard app that Plone is: both an out-of-the-box CMS _and_ a "site
platform". Specifically, Kotti has features that make it more
suitable for complex intranet applications where flexible security
(groups, local roles, workflow) is needed.
Maybe I should reconsider calling it a "simple CMS". Harr!
Michael Bayer
On Tue, 2011-12-13 at 01:59 -0800, rihad wrote:
You are presuming that there is a one true form library that does
everything well that is completely satisfactory in all cases. I can
tell you from pretty hard experience that this is not true. To the
extent that I recommend a single form library, I tend to recommend
Deform because a) I wrote it and b) it's a Pylons project. But I always
qualify my recommendation of it with "it's great for autogenerating
forms, but it's not so great if you want pixel-control over the layout".
For that, I tend to recommend pyramid_simpleform (also a Pylons
project).
Eric Rasmussen
If your mental model of a website can be fully accommodated by the features in other frameworks, there's always the argument that they would be a better starting place than Pyramid. In my case, I've needed to rethink the notion of "web app" more than once, and Pyramid has been there consistently and successfully as my foundation.
Benjamin Sims
Michael Bayer
Mike Orr
This is a longstanding debate that goes back several years, whether
Pyramid (and Pylons 1) is the right size or too small. You're right
that many users want the framework to choose a
form/javascript/ORM/CRUD/authentication/etc library for them, and that
this is a major reason for the popularity of Django, TurboGears, etc.
Pyramid is a new project, and its tutorials and add-ons are still
being written. As Chris said, we want all those things to happen, but
*outside the Pyramid core*. In autonomous packages not constrained by
all of Pyramid's rules and release schedule, where multiple developers
can offer different and possibly contradictory solutions.
The type of form library is a good example. Two schools of thought
exist: (1) automatically generate a form based on a data model, (2)
allow the user to override and customize how each form element looks
and where it's placed. FormAlchemy is the former;
FormEncode/WebHelpers is the latter. ToscaWidgets is a larger example
of the former: by adding more features and Javascript plugins it
becomes significantly bigger and more complex. All of these features
are a positive for some people and a negative for others. If a future
Pyramid/ToscaWidgets bundle (TurboGears 3) exists someday, it would
please some users. But others would be turned off, and others would
find it *difficult* to express their application's requirements in
that system. If Pyramid offered ToscaWidgets in the core, those users
would have to painstakingly work around it, and would have to suffer
several large dependencies which they're not using. But by pushing the
decision to a higher level, Pyramid pleases both modular-favoring
users and full-stack favoring users: everybody except those who wish
the full stack were in the core. We're trying to offer a different
framework *paradigm*: one where high-level frameworks are in
super-distributions, and you can choose from more than one of them.
By lightweight I mean a framework that has only the bare essentials
for request processing: query parameters and the like, and maybe a
session interface. The small frameworks I mentioned went that route. I
used to use Quixote because of this: I liked the fact that I could
print out the entire source and read and understand it in half an
hour. But I got tired of writing and maintaining my own template
interface, database interface, session persistence, and
authentication. (This was before Mako, SQLAlchemy, and Beaker
existed.) I wanted to use plugins written by experts and maintained by
a community. That led me to Pylons, which had more of these things
built in. But I also valued ultra-modularity, so I could not choose
Django, and TurboGears was in too rough shape then.
But TurboGears created an innovation which has benefitted all
frameworks since. Originally it was a "decide-for-you" framework. Kid
templates, SQLObject ORM, and I forget which Javascript library. But
*ALL* of these became obsolete, out from under the framework. Even
from the beginning, many users wanted to use Cheetah templates rather
than Kid. (Kid was similar to Chameleon; Cheetah was similar to Mako.)
So TurboGears invented a template front end called Buffet, which
allowed different template engines to plug into the framework. This
pleased everybody: those who wanted an official template engine, and
those who wanted alternatives. Buffet was ported to Pylons 0.9.7, and
a simpler version of the concept was ported to Pyramid. So you see,
if TurboGears had rigidly stuck to its original decisions, it would be
stuck in obsolete-land and would never have taken off.
If you have specific questions about which libraries to use on top of
Pyramid, such as which form library to choose, describe what kind of
form API or "workflow" you expect, and we can suggest something the
most similar. Do you just want a quick-and-easy form based on an
object-oriented model? Do you want to control precisely how the form
looks? Do you require Javascript, or do you have external Javascript
you want to integrate? All these point to a different subset of form
libraries.
--
Mike Orr <slugg...@gmail.com>
rihad
> If you have specific questions about which libraries to use on top of
> Pyramid, such as which form library to choose, describe what kind of
> form API or "workflow" you expect, and we can suggest something the
> most similar. Do you just want a quick-and-easy form based on an
> object-oriented model? Do you want to control precisely how the form
> looks? Do you require Javascript, or do you have external Javascript
> you want to integrate? All these point to a different subset of form
> libraries.
>
Nice posting there. As for the forms, you're right, I'd like them to
be pre-generated based on the model, with the ability to pull
validation constraints from it, and fill the form errors in case of
constraint violations. Both at the field-level, and at the overall
form-level, detecting arbitrary cross-field inconsistencies based on
custom validation defs. Just how Django does with its ModelForm. Of
course adding any extra custom fields should be possible, too. And it
would be perfect if the basic constraint checking (like min/max, non-
empty, etc.) were duplicated in the client-side JS code, to save a
round-trip to the server.
The whole idea is to stick to the DRY principle - keep data in one
place. The model's data options should be all that is necessary to
present a form, validate it, and store the data. Plus any custom
validation defs, of course.
Vlad K.
Which is in my view exactly the power of Pyramid. By combining libs that
do one job and do it well (like in "The UNIX Way"), one can build an
application with Pyramid which is far, far more advanced at given
task(s) than any full-stack solution limited only to what its stack is
mandating.
.oO V Oo.
rihad
On Dec 14, 12:23 am, "Vlad K." <v...@haronmedia.com> wrote:
> Which is in my view exactly the power of Pyramid. By combining libs that
> do one job and do it well (like in "The UNIX Way"), one can build an
> application with Pyramid which is far, far more advanced at given
> task(s) than any full-stack solution limited only to what its stack is
> mandating.
>
I totally agree. But this comes at a cost: you have to be nearly just
as proficient and experienced as its authors to appreciate its full
power.
Michael Merickel
I totally agree. But this comes at a cost: you have to be nearly just
as proficient and experienced as its authors to appreciate its full
power.
Mengu
i wonder if you have tried TurboGears 2 or not and if you had what
pushed you away from it. what you are asking for pyramid are already
available with TG.
Danny Navarro
Another thing from Pyramid that's frequently forgotten are its scaffolds. You can get some instant full stack framework gratification with scaffolds like Akhet or Khufu. However, for a newcomer the brand he's heard the most is Pyramid. I don't know if giving more prominence to these sccafolds wherever potential users start reading, and encouraging to quickstart magically with them, will make Pyramid less intimidating.
>
> --
> Mike Orr <slugg...@gmail.com>
rihad
Actually I've spent a few days to read all the docs to get as much
info as possible (http://docs.pylonsproject.org/projects/pyramid/en/
1.3-branch/), and the SQLalchemy wiki tutorial before attempting to
start a project I had on my mind. But I still wasn't sure which high-
quality extension to pick to generate forms, validate the data etc.,
at least not until I knew that the author of Pyramid also wrote
Deform. So I'll be starting from there. But it's a pity if if that
would require me to duplicate data in more than one place (model/form/
validation). Deform docs (http://docs.pylonsproject.org/projects/
deform/en/latest/basics.html) seem to completely ignore any notion of
models, or data sources, offering users to create a schema anew.
Sometimes some kind of coupling is needed.
Chris McDonough
> On Dec 14, 12:55 am, Michael Merickel <mmeri...@gmail.com> wrote:
> > On Tue, Dec 13, 2011 at 2:29 PM, rihad <ri...@mail.ru> wrote:
> > > I totally agree. But this comes at a cost: you have to be nearly just
> > > as proficient and experienced as its authors to appreciate its full
> > > power.
> >
> > Actually it just means you have to read the documentation to use it. You
> > can't just sit down and magically write a blog in 5 minutes while not
> > caring about where the forms, data, sessions, auth, etc are coming from.
> > You'll need to read the docs eventually anyway, but to use something that
> > isn't full stack, you usually have to read the docs first.
>
> Actually I've spent a few days to read all the docs to get as much
> info as possible (http://docs.pylonsproject.org/projects/pyramid/en/
> 1.3-branch/), and the SQLalchemy wiki tutorial before attempting to
> start a project I had on my mind. But I still wasn't sure which high-
> quality extension to pick to generate forms, validate the data etc.,
> at least not until I knew that the author of Pyramid also wrote
> Deform. So I'll be starting from there.
Great.
> But it's a pity if if that
> would require me to duplicate data in more than one place (model/form/
> validation). Deform docs (http://docs.pylonsproject.org/projects/
> deform/en/latest/basics.html) seem to completely ignore any notion of
> models, or data sources, offering users to create a schema anew.
> Sometimes some kind of coupling is needed.
You are responsible for supplying that coupling by generating a Deform
schema from a SQLAlchemy schema. It's likely that someone (maybe you
even) will eventually create a generic package for doing that schema
generation; one does not exist now.
- C
rihad
by another session-based plugin at the discretion of the developer?
Like, opt-in security? :)
Also, the docs say that some form controls rely on JS being available.
That's understandable, like in the case of date-time controls. Still
it would be great if the generated HTML targeted both JS-on and JS-off
users via <noscript>. Like a fuzzy scripted date widget vs. simple
combo-boxes to do the same thing.
Chris McDonough
> Hi, Chris. Since Deform doesn't mention CSRF, I assume it must be done
> by another session-based plugin at the discretion of the developer?
> Like, opt-in security? :)
http://deformdemo.repoze.org/pyramid_csrf_demo/
Maybe you could tone down the snark ala "like, opt-in security"? It's
pretty off-putting.
> Also, the docs say that some form controls rely on JS being available.
> That's understandable, like in the case of date-time controls. Still
> it would be great if the generated HTML targeted both JS-on and JS-off
> users via <noscript>. Like a fuzzy scripted date widget vs. simple
> combo-boxes to do the same thing.
It doesn't out of the box, but you can register your own widgets for
schema types if you really need to:
http://docs.pylonsproject.org/projects/deform/en/latest/widget.html
- C
rihad
rihad
validation error occurs?
Chris McDonough
> Doesn't Deform fill in the form with the values submitted when a
> validation error occurs?
Can you describe what's unclear about
http://docs.pylonsproject.org/projects/deform/en/latest/basics.html#validating-a-form-submission
- C
rihad
On Dec 14, 11:34 pm, Chris McDonough <chr...@plope.com> wrote:
> On Wed, 2011-12-14 at 07:19 -0800, rihad wrote:
> > Doesn't Deform fill in the form with the values submitted when a
> > validation error occurs?
>
> Can you describe what's unclear abouthttp://docs.pylonsproject.org/projects/deform/en/latest/basics.html#v...
>
I'm very sorry, my bad. I had
if request.POST:
try:
form_data = myform.validate(request.POST.items())
except ValidationFailure, e:
return { 'form': e.render() }
rendered_form = myform.render()
return { 'form': rendered_form }
When there were no validation errors myform.render() still showed
"There was a problem with your submission blah blah", leaving the
field empty. "myform" must still have form errors attached to it,
although not previously entered data.
rihad
to install pyramid_formalchemy for pyramid-1.3a2-py2.7. I've
easy_installed pyramid_formalchemy with its dependencies, added
'pyramid_formalchemy',
'fa.jquery',
to "requires" in setup.py and rerun "setup.py develop". The doc then
tells me to run "paster create -t pyramid_fa". Since "paster create"
has now been superseded by pcreate, I do this instead:
$ pcreate -t pyramid_fa myapp
Unavailable scaffolds: ['pyramid_fa']
$ pcreate -l
Available scaffolds:
alchemy: Pyramid SQLAlchemy project using url dispatch
starter: Pyramid starter project
zodb: Pyramid ZODB project using traversal
How should I fix this?
Thanks.
Chris McDonough
pyramid_formalchemy likely still relies on Paste for its scaffolding:
$ yourvirtualenv/bin/easy_install PasteScript
$ yourvirtualenv/bin/easy_install pyramid_formalchemy
$ yourvirtualenv/bin/paster create --list-templates
- C
rihad
first:
$ paster create --list-templates
Available templates:
basic_package: A basic setuptools-enabled package
paste_deploy: A web application deployed through paste.deploy
pylons_fa: Pylons application template with formalchemy support
pyramid_fa: Pyramid application template to extend other
templates with
toscawidgets: ToscaWidgets widget
but...
$ paster create -t pyramid_fa sol
...
RuntimeError: Under Pyramid 1.3, you should use the "pcreate" command
rather than "paster create"
and pcreate can't find the "pyramid_fa" scaffold, so it looks like
another one of those chicken and *.egg problems.
rihad
Gael Pasgrimaud
> Is going back to 1.2 the only way to try pyramid_formalchemy out?
>
No, you don't really need a template. You can add pyramid_formalchemy
to a project with only a few extra lines to your __init__.py:
config.include('pyramid_formalchemy')
config.formalchemy_admin('/admin', package='yourpackage')
That's it.
There is also some examples of various configuration/settings used for
testing here: https://github.com/FormAlchemy/pyramid_formalchemy/tree/master/pyramidapp/pyramidapp
Chris McDonough
> Is going back to 1.2 the only way to try pyramid_formalchemy out?
That'd be the easiest way, at least until pyramid_formalchemy is updated
to work with Pyramid 1.3.
- C
Chris McDonough
For the record, how to update scaffolding is docmented here, Gael...
Gael Pasgrimaud
Added to master. Thanks.
Jonathan Vanasco
I've built dozens of sites over the past 14 or so years , with Ad
Agencies, Large Brands, Tech Startups, Major Media companies.
Doing this, I've learned that Frameworks are really really great for
the run-of-the-mill project that has a quick deadline, doesn't do
anything new & exciting, and has a shelf-life ( ie, it's expected to
last 6-18 months and then it gets turned off ).
For anything that needs constant improvement, nurturing, active
product development and scaling of user interactions... frameworks
have always been a complete fucking nightmare. Time and time again,
I've seen my colleagues hit their heads against a wall ( often
literally ) and wasting countless cycles trying to get around a
'design' or 'convenience' of a framework. I've also often seen months
of work for projects that built on a framework thrown out and replaced
with entirely custom Java/C/Python/etc code to solve the issues.
I'm a big fan of using the right tool for the right job. If I'm
needing to do a simple project that a 'framework' can quickly get off
the ground and not need to maintain/grow it outside of that framework
-- fine! But I'm well past the point in my career where I can justify
saving an extra week off the initial launch plan to go with a
convenience framework, when I know that I'm damning my dev staff to
mundane and crap tasks like spending a week to customize a pagination
plugin to work within the confines of that framework.
I became a huge fan of Pylons/Pyramid , because a large majority of
the stuff that lead people tend to abandon frameworks during project
growth can be - and is easily - done within the environment.
On Dec 13, 4:59 am, rihad <ri...@mail.ru> wrote:
> So it's a perfect tool for writing a framework :)
> Lightweight in my understanding means few features, mostly glue code.
> Just like Pyramid. All other meaty, but nonetheless important
> features, are meant to be chosen by a developer using that framework,
> and plugged in. For example, AFAIK Pyramid has no Form/validation
> subsystem in its core, or even an "official" plug-in that it endorses.
> Through trial and error, you have to just pick the missing part from
> the plethora of what's available, that would suit you functionally and
> esthetically. Maybe in the long run this would make you a more savvy,
> professional developer. But you'll have to agree with me, that if our
> goal is to build bigger, less buggy programs, we're gonna have to
> abstract from smaller details, use bigger bricks, so to speak. That's
> why people have chosen C, not assembly to write most parts of a larger
> OS; PHP, Perl or Python over C for web work, Frameworks over plain
> PHP, Perl or Python to facilitate building even larger programs. And
> that's because a human, however smart he or she is, cannot hold all
> the miniscule details in his head. People can see the bigger picture
> more clearly. So unless there's a larger framework built on top of
> Pyramid, as it is now the learning curve of getting the needed tools
> and do some CRUD/DB/auth/form edit/add, lists/pagination with some
> custom functionality - is pretty slow.
rihad
On Dec 18, 12:52 am, Gael Pasgrimaud <g...@gawel.org> wrote:
> On Sat, Dec 17, 2011 at 9:41 PM, rihad <ri...@mail.ru> wrote:
> > Is going back to 1.2 the only way to try pyramid_formalchemy out?
>
> No, you don't really need a template. You can add pyramid_formalchemy
> to a project with only a few extra lines to your __init__.py:
>
> config.include('pyramid_formalchemy')
> config.formalchemy_admin('/admin', package='yourpackage')
>
> That's it.
>
> There is also some examples of various configuration/settings used for
> testing here:https://github.com/FormAlchemy/pyramid_formalchemy/tree/master/pyrami...
>
Thanks. But what about the config.include('myapp.fainit') thing from
the doc? What does it do? I don't see it being mentioned later. The
line should probably go to __init__.py and fainit.py should be found
in the $myapp/ dir with the def includeme in it.
Gael Pasgrimaud
fainit just define the route for you. but you can check that by yourself:
rihad
On Dec 18, 12:52 am, Gael Pasgrimaud <g...@gawel.org> wrote:
> On Sat, Dec 17, 2011 at 9:41 PM, rihad <ri...@mail.ru> wrote:
> > Is going back to 1.2 the only way to try pyramid_formalchemy out?
>
> No, you don't really need a template. You can add pyramid_formalchemy
> to a project with only a few extra lines to your __init__.py:
But it won't work:
$ pserve --reload development.ini
...
import zope.component.event
ImportError: No module named component.event
So I guess this is true:
> That [going back to 1.2]'d be the easiest way, at least until pyramid_formalchemy is updated
rihad
> ...
Gael Pasgrimaud
Look like zope.component api have changed (?). Try to install
zope.component-3.12.0. This one work for me
Btw, you should use the formalchemy mailing list.
Gael Pasgrimaud
It's now pyramid 1.3+ compatible and the pyramid_fa scaffold is also up to date.
For now I've added zope.component as a dependencie (pyramid removed it
because of the py3 compat I guess)
[1] http://docs.formalchemy.org/pyramid_formalchemy/