hi -
i've written a project that lets you transfer stuff easily to and from
forms and data objects. y'all are welcome to use it. it's at http://aspbeans.sourceforge.net . feel free to email me suggestions :)
thanks!
terry 23  1137 
by the time I write all the bean files and xml files , it seems I could just
as well write the DAL ?
"theath" <th****@gmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com... hi -
i've written a project that lets you transfer stuff easily to and from
forms and data objects. y'all are welcome to use it. it's at
http://aspbeans.sourceforge.net . feel free to email me suggestions :)
thanks!
terry
you only really need to write the xml files if you've got some complex
things going on with the forms, or you're using legacy apps. if you're
writing a database driven application, hopefully you already have the
beans, so it should just plug in and cut out code :)
I just don't see the benefit ?
"theath" <th****@gmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com... you only really need to write the xml files if you've got some complex
things going on with the forms, or you're using legacy apps. if you're
writing a database driven application, hopefully you already have the
beans, so it should just plug in and cut out code :)
well, take a somewhat large form with a complicated datagrid. you can
populate, save, navigate through the columns by hand, and do all of
that good stuff with one line of code for each way of the transfer, or
you can do it with 2 lines of code (not counting xml situps).
that you can make changes in one layer without having to significantly
alter another, or hopefully not at all, is a fairly big benefit i
think. further, it reduces ties between the controller and the
presentation, enforcing MVC paradigms better.
that's where i see the benefit. things like RoR and JSP already offer
(fairly similar) ways to do this, but i didn't know of anything that
did it in .net so i slapped one together.
i'm planning on putting in validation, so you can write custom
validators without having to pollute your code with that either.
the main idea, i suppose is to reduce redundant code and allow
developers to focus on their logic and control, instead of doing tons
of trivial stuff. if you've got any suggestions that you'd think would
make it more clearly beneficial to you, i'm definitely open to them :)
if it's a small project, though, then it might be a pain to implement
the separate layers and everything else. i'd say the same goes for
things like (n)hibernate, ibatis, struts, or anything else.
Your solution (as I understand it) is one step over binding (I might be
wrong). Still, it looks interesting.
One of the things that I dislike about WebForms is the fact that we went
from "generate x input field if condition y" to "hide x input field if
condition y".
Using dynamically loaded controls is sometimes impractical because of the
way the event model works, and the fact that they may interact with each
other and cause these conditions to change. Your "state machine" can get
complicated real fast. Panels alleviate some of this, but they're not very
flexible. You're also almost forced to "carry" some state in a session or
cookie instead of in the ViewState. This of course does not apply to
controls that are merely visual and don't have events (don't get me started
on the IDE quirks with WebControl events). And of course it's almost
impossible to use the POST data directly because of control ID mangling.
It seems to me that you'd get bigger bang for your buck if you designed a
framework that can solve these problems =)
Just a thought.
--
Klaus H. Probst, MVP http://www.simulplex.net/
"theath" <th****@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com... well, take a somewhat large form with a complicated datagrid. you can
populate, save, navigate through the columns by hand, and do all of
that good stuff with one line of code for each way of the transfer, or
you can do it with 2 lines of code (not counting xml situps).
that you can make changes in one layer without having to significantly
alter another, or hopefully not at all, is a fairly big benefit i
think. further, it reduces ties between the controller and the
presentation, enforcing MVC paradigms better.
that's where i see the benefit. things like RoR and JSP already offer
(fairly similar) ways to do this, but i didn't know of anything that
did it in .net so i slapped one together.
i'm planning on putting in validation, so you can write custom
validators without having to pollute your code with that either.
the main idea, i suppose is to reduce redundant code and allow
developers to focus on their logic and control, instead of doing tons
of trivial stuff. if you've got any suggestions that you'd think would
make it more clearly beneficial to you, i'm definitely open to them :)
if it's a small project, though, then it might be a pain to implement
the separate layers and everything else. i'd say the same goes for
things like (n)hibernate, ibatis, struts, or anything else.
that's my point, all that xml looks to be horrific compared to simply
passing in a connection and a query string to a datagrid assembly.
A typical assembly will generate a pageable, sortable datagrid with add/
edit/ delete functionality for any query string it receives.
no xml required, that's simple .
That's a good point that passing in a connection string to a dg will
make things easier, but it's also considered dirtier, at least from my
perspective. I try to make my pages and logic storage/model
independent, so if it's coming from a database that's nice, but it's
not necessary. If you're using something like ibatis (ugh) or hibernate
(yay), moving from dev to prod really only takes a change of a config
file for indicating what database you're going to. You could do
something similar with a web.config, but there's still a higher amount
of coupling (and layer crossing) than I like.
I've been playing with RoR lately, and the way it generates scaffolding
for CRUD operations is really impressive. I'm just not sure of a way to
make use of that with a datagrid, because I don't know how people will
want things ordered. Since you seem to like datagrids, how would you
want it done?
You're pretty much right. It doesn't do much beyond just tying the form
to the object right now. I think things that would be nice to add are:
*more flexible and available validation
*dynamically created forms (like RoR scaffolding)
I'm not sure if that stuff solves the problems you provide, but it's a
start :)
One of the problems I run into here is that some people like to put
<b>all</b> of their logic in the page behinds, which to me seems like a
horrible practice. I guess I'm more of a purist, but I'm trying to keep
as much logic as possible out of there. I wrote up aspbeans to try to
alleviate some of it, because then people seemed to not take over the
save/load logic, and then they just let the model take care of itself.
Since I've played with RoR, I'm wondering if there's not some way I
could do something similar to that for ASP. I wouldn't even mind
implementing something more struts-like, because I think the idea of
having actions and clear-cut controllers instead of hacked-together
pages seems a lot cleaner.
I don't think that really answers your suggestion, though. I agree that
hiding web controls doesn't seem like a very sound solution. I'd rather
either a) make a separate page for each of those cases, using actions
(see above crazy implementation idea :), or b) have aspbeans have some
logic such that when it's creating a form, it can check that and not
create the control if it's there. I think either of these solutions is
going to require some growth in the framework, but that's what I'm
hoping for out of your suggestions :).
I'm not sure I understand your complaint about viewstate stuff, though.
If you want to go into it more, maybe I can address it :)
Thanks for your suggestions guys, that's what I was hoping for.
terry
This sort of de-coupling is nice, and very useful in some situations.
However, it also adds complexity and overhead to an app. It should be noted
that the Java way of doing things is partially an outgrowth of the "non-MS"
environment, in which platforms are highly proprietary in nature, by virtue
of the fact that the Unix community is so diverse. MS provides a much more
uniform platform, and often this level of de-coupling can be avoided. Loose
coupling is a good concept; however, I have seen it taken too far from time
to time.
Note that this is not a comment on your project per se, but an observation
sparked from this conversation.
--
Kevin Spencer
Microsoft MVP
..Net Developer
The sun never sets on
the Kingdom of Heaven
"theath" <th****@gmail.com> wrote in message
news:11*********************@g47g2000cwa.googlegro ups.com... That's a good point that passing in a connection string to a dg will
make things easier, but it's also considered dirtier, at least from my
perspective. I try to make my pages and logic storage/model
independent, so if it's coming from a database that's nice, but it's
not necessary. If you're using something like ibatis (ugh) or hibernate
(yay), moving from dev to prod really only takes a change of a config
file for indicating what database you're going to. You could do
something similar with a web.config, but there's still a higher amount
of coupling (and layer crossing) than I like.
I've been playing with RoR lately, and the way it generates scaffolding
for CRUD operations is really impressive. I'm just not sure of a way to
make use of that with a datagrid, because I don't know how people will
want things ordered. Since you seem to like datagrids, how would you
want it done?
I've gotta agree with you that sometimes people take design stuff too
far, but lots of times they dont' take it far enough, either :) There
seems to be some middle ground which is great but hard to get at.
I think that the unix way of approaching things is better when it comes
to the developer community, because it creates amazing tools like
struts, hibernate, ibatis (not my favorite but still a nice tool). With
MS, lots of developers don't feel the pain of their coding practices
because they haven't been exposed to things that make life easier, like
ORMs and action-control instead of page-control.
Just my $0.02 here.
> I've gotta agree with you that sometimes people take design stuff too far, but lots of times they dont' take it far enough, either :) There
seems to be some middle ground which is great but hard to get at.
I agree completely. The real skill is to be able to find that "golden mean."
Have a great weekend.
--
Kevin Spencer
Microsoft MVP
..Net Developer
The sun never sets on
the Kingdom of Heaven
"theath" <th****@gmail.com> wrote in message
news:11*********************@g47g2000cwa.googlegro ups.com... I've gotta agree with you that sometimes people take design stuff too
far, but lots of times they dont' take it far enough, either :) There
seems to be some middle ground which is great but hard to get at.
I think that the unix way of approaching things is better when it comes
to the developer community, because it creates amazing tools like
struts, hibernate, ibatis (not my favorite but still a nice tool). With
MS, lots of developers don't feel the pain of their coding practices
because they haven't been exposed to things that make life easier, like
ORMs and action-control instead of page-control.
Just my $0.02 here.
> I've gotta agree with you that sometimes people take design stuff too far, but lots of times they dont' take it far enough, either :) There
seems to be some middle ground which is great but hard to get at.
I agree completely. The real skill is to be able to find that "golden mean."
Have a great weekend.
--
Kevin Spencer
Microsoft MVP
..Net Developer
The sun never sets on
the Kingdom of Heaven
"theath" <th****@gmail.com> wrote in message
news:11*********************@g47g2000cwa.googlegro ups.com... I've gotta agree with you that sometimes people take design stuff too
far, but lots of times they dont' take it far enough, either :) There
seems to be some middle ground which is great but hard to get at.
I think that the unix way of approaching things is better when it comes
to the developer community, because it creates amazing tools like
struts, hibernate, ibatis (not my favorite but still a nice tool). With
MS, lots of developers don't feel the pain of their coding practices
because they haven't been exposed to things that make life easier, like
ORMs and action-control instead of page-control.
Just my $0.02 here.
"coupling", "layer crossing", "scaffolding" ??
I get that you're not from around here.
passing in a connection and query string to a dg is not "dirtier" .
It's extremely clean and efficient coding, using pre-compiled assemblies.
If you are trying to eliminate CRUD, there are already many ORM's/Template
code generators readily available and come with or without UI's, including
the dotnet version of hibernate called Nhibernate which is supported by some
ORM's that also provide a UI.
Before you attempt to reinvent the wheel, you may want to look into some of
these.
Well, it seems to me that having the presentation be model-specific is
wrong. I guess I'm from a slightly different background, one that isn't
nearly as enforced in .net.
In .net, it seems lots of people are happy putting their code and logic
in code behinds, and that there's very little sense of separation
between controllers, presentations, and models.
Just because that's the popular way to do things doesn't mean that it's
the right way.
I'm a huge fan of MVC paradigms, because I find that they make things
easier to maintain and distribute among a large number of developers.
I'm going to have to disagree with your statement that using a
connection string with a dg is cleaner. That's incredibly specific to
your model. Change databases and you have to change your code. Change a
table name and you have to change your code. If you're using a data
layer like hibernate (nhibernate is a decent solution for .net, though
it lags significantly behind hibernate I've found), you won't have to
touch your code, only a few xml files.
Like I said before, lots of .net developers don't understand the pain
they're suffering until they see something else. The more I talk about
it, the more I want to turn aspbeans into a framework similar to RoR.
If you're not a proponent of MVC paradigms, then aspbeans isn't for
you. Then again, ASP isn't really, either. From my experience, if
you're just coding applications and don't care where the code goes or
things like that, why not just go with PHP?
Have a good night!
terry
Things you say don't make sense. some people put their code in code-behind
specifically to separate presentation from processing.
As it turns out, when calling an assembly, using code behind is optional.
some people use it, some don't.
I don't change my code when I change databases. The connection string is
passed in as a property to the assembly. It doesn't care what the
connection string is, or the database. Same with the query string, it is
also passed in as a property which then defines the tables, fields , order
etc. If I change databases, I have to change the connection string anyway,
and it's always stored as a constant for the entire application. Similarly,
if I alter the tables or fields I have to change the querystring anyway.
The assembly never gets touched.
As for a data layer, it isn't even involved here. My sense is, you don't
fully understand ASP.net
"theath" <th****@gmail.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com... Well, it seems to me that having the presentation be model-specific is
wrong. I guess I'm from a slightly different background, one that isn't
nearly as enforced in .net.
In .net, it seems lots of people are happy putting their code and logic
in code behinds, and that there's very little sense of separation
between controllers, presentations, and models.
Just because that's the popular way to do things doesn't mean that it's
the right way.
I'm a huge fan of MVC paradigms, because I find that they make things
easier to maintain and distribute among a large number of developers.
I'm going to have to disagree with your statement that using a
connection string with a dg is cleaner. That's incredibly specific to
your model. Change databases and you have to change your code. Change a
table name and you have to change your code. If you're using a data
layer like hibernate (nhibernate is a decent solution for .net, though
it lags significantly behind hibernate I've found), you won't have to
touch your code, only a few xml files.
Like I said before, lots of .net developers don't understand the pain
they're suffering until they see something else. The more I talk about
it, the more I want to turn aspbeans into a framework similar to RoR.
If you're not a proponent of MVC paradigms, then aspbeans isn't for
you. Then again, ASP isn't really, either. From my experience, if
you're just coding applications and don't care where the code goes or
things like that, why not just go with PHP?
Have a good night!
terry
TJS wrote: "coupling", "layer crossing", "scaffolding" ??
I get that you're not from around here.
passing in a connection and query string to a dg is not "dirtier" .
It's extremely clean and efficient coding, using pre-compiled
assemblies.
You're confusing coding and application architecture.
Ouch.
-- http://www.joergjooss.de
mailto:ne********@joergjooss.de
I don't really understand what you're saying. I think the guy below
said what I'm thinking, that you're talking about code versus design.
I'm not talking about the merits of a code behind. I'm talking about
the poor design that it encourages.
A data layer is somewhat important here. Aspbeans is much easier to use
if you have some bean like objects already written, which you hopefully
do if you're writing database-driven code.
I think this is where we differ: you'll let a datagrid directly
manipulate data fed from a database; I don't do that. I feed objects
into datagrids, because I think that the presentation ought to pass
changes to controllers (and subsequently to modles) that affect
objects, not directly the database. This provides more power, easier
consistency checking, and cleaner code. You can argue all you want with
it, but looking at the number of projects that are coming out that are
trying to reduce the strong ties to a database, I think I'm in the
majority here.
hard to say which topic is applicable considering we're talking about so
called "asp-beans"
"Joerg Jooss" <ne********@joergjooss.de> wrote in message
news:xn****************@msnews.microsoft.com... TJS wrote:
"coupling", "layer crossing", "scaffolding" ??
I get that you're not from around here.
passing in a connection and query string to a dg is not "dirtier" .
It's extremely clean and efficient coding, using pre-compiled
assemblies.
You're confusing coding and application architecture.
Ouch.
--
http://www.joergjooss.de
mailto:ne********@joergjooss.de
i know you're defending your baby so I'll let my comments stand .
Eh, I'm trying to solicit suggestions from other developers on ways to
make the concept better, so more people can use it and it will make
apps easier. Thanks for what you offered :)
TJS wrote: hard to say which topic is applicable considering we're talking about
so called "asp-beans"
Let's be more specific then:
"passing in a connection and query string to a dg is not "dirtier" ."
This is completely impossible in a loosely coupled 3-tier architecture.
Technology-specific classes bound to a tier simply stay there. The Web
UI has no access to DBMS connections, and shouldn't know what kind of
persistence mechanism is used.
"It's extremely clean and efficient coding, using pre-compiled
assemblies."
Yes, it's efficient *coding*, but it is also a horrible architecture.
Cheers,
-- http://www.joergjooss.de
mailto:ne********@joergjooss.de
theath wrote: Eh, I'm trying to solicit suggestions from other developers on ways to
make the concept better, so more people can use it and it will make
apps easier. Thanks for what you offered :)
I had only a brief look at it, but did you use Spring or Spring.NET as
an inspiration here?
Cheers,
-- http://www.joergjooss.de
mailto:ne********@joergjooss.de
I've heard about spring, but I haven't looked at it much yet. If it
already does what I'm doing, maybe I should build off of that :)
What I'd really like to do is patch together some framework consisting
of an ORM (using an existing one; that's beyond me :), a way to write
from/populate to forms easily, and a way to handle actions that would
create a sound framework for ASP.
My main inspiration was actually the work I've been doing. We've
created a fairly large web-based app with tons of forms, and everybody
seemed to have their own way to save the data. It was pretty difficult
to maintain, so I figured I might as well present a semi-standard for
it. Hopefully, with suggestions and other ideas (and, most importantly,
time, which I seem to be short on lately), the thing can grow into a
pretty helpful framework for developers.
Hope you're having a good weekend!
terry
This thread has been closed and replies have been disabled. Please start a new discussion. |
