Sample Application Collaboration Invitation
Dan Wilson
- better theming support
- print friendly messages
- multi-homing (support for multiple forums in a single code base)
- as well as any other low hanging fruit gained by a refactor to MG3
- How to use current Model-Glue 3 features for Rapid Development
- What we can improve about Model-Glue 3 for Rapid Development
- How to plan and structure a greenfield project for the fastest possible development
- Build a great piece of Open Source software for the community to use and learn from
DW
--
“Come to the edge, he said. They said: We are afraid. Come to the edge, he said. They came. He pushed them and they flew.”
Guillaume Apollinaire quotes
Chuck Savage
Galleon would be cool, I currently use it.
I don't know what you have in mind for conference, other than that one
word, you didn't explain anything else. I'm just curious if Google
Wave doesn't already do it all.
Perhaps a merchant site would help many, since those kind of sites are
built all the time.
Dennis Clark
I don't know what you have in mind for conference, other than that one
word, you didn't explain anything else. I'm just curious if Google
Wave doesn't already do it all.
Rich
Instead of designating a specific application I would love to see something along the lines of application pieces, bigger than snippets but commonly used items of an app like menuing, navigation, shopping cart, portal pieces, communication elements (something that might incorporate video/podcasts/Connect sessions, etc.), basic and advanced security.... than maybe we could branch off and build out a few little mini-apps that leverage these pre-built code modules. Something along the lines of action packs but that which could plug into a main controller (taking controller out of the MVC context.... or am I? ;-) )
A lot of us are still bridging the gap between inherited procedural code and new apps that we're building in MVC, so if we could pull something like this together I'd have to think it would give the MG framework an edge up on all of the other frameworks, since, at least from what I've seen, they're all assuming a base level understanding of OOP and MVC. What I'm rambling on about here is, if we can start with some basic pieces, assuming little to nothing other than basic CF experience than we can readily leverage parts and pieces into bigger things while preserving, even promoting the original mantra of ColdFusion, which was rapid application development.
I'd be up for helping develop and/or test.
My 2 cents worth, and thanks again to this very supportive group.
Rich
Rich Leach
Advanced Certified Adobe ColdFusion Developer
ri...@cfsnap.com
http://www.cfsnap.com
303-913-7338
Instant Messenger:
AOL AIM: cfsnaprich
Instant Video Conference:
APPLE MobileMe: rich...@me.com
> --
> Model-Glue Sites:
> Home Page: http://www.model-glue.com
> Documentation: http://docs.model-glue.com
> Bug Tracker: http://bugs.model-glue.com
> Blog: http://www.model-glue.com/blog
>
> You received this message because you are subscribed to the Google
> Groups "model-glue" group.
> To post to this group, send email to model...@googlegroups.com
> To unsubscribe from this group, send email to
> model-glue+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/model-glue?hl=en
Lola Lee Beno
> I don't know what you have in mind for conference, other than that one
> word, you didn't explain anything else. I'm just curious if Google
> Wave doesn't already do it all.
>
>
My interpretation of the conference application is that it would enable
one to set up a conference, like cfObjective, CFinNC, etc. Such
conference takes a lot of planning - you have to plan for how many days
the conference runs, you have to arrange for speakers and time slots, as
well as subjects. And you have to set up a registration process and
ensure that everyone paid up, got their conference package, etc.
Haven't seen any CF application that does all this.
--
Lola J. Lee Beno
LinkedIn: http://www.linkedin.com/in/lolajleebeno
Facebook: http://www.facebook.com/profile.php?id=714355583
Blog: http://www.lolajl.net/blog/
Chris Blackwell
--
Roy Martin
framework and finished and made it a working framework by adding the
additional events and replacing the rest of the links necessary to
make this work. However, all this did was simply provide a mg wrapper
to include the correct views by a model-glue event-handler. The
biggest problem with this is that galleon does not abstract the link
locations, so incorporating view changes that contained bug fixes is a
manual process. This was nice because it was easy to incorporate your
own security or other pre-written MG broadcast, but otherwise didn't
buy us much. I could see this being helpful for theming but what are
your thoughts on how much you want to truely fork galleon into a MG
project?
What I would love to see is more effort and support around
actionpacks. I think that's one of the least explored but most
powerful feature of MG. There is currently not much documentation,
sample resouces or central repository around this. If we did work
together for a project like event / conference management I would push
to have that contain a series of reusable actionpacks (payment
actionpack, event management actionpack, etc). We could then kick-off
a actionpack listing or repo where. We could add these and allow
others to add them as well, similar to a cflib or riaforge. That's
what I would really like to see some effort put into as we push for
standard ways to build components that can be reused using MG. We have
several that we can contribute as well as this has been a big focus
for us internally.
That's my 2 cents,
Roy
On Monday, December 28, 2009, Chris Blackwell <ch...@team193.com> wrote:
> sounds like fun!I'd be particularly interested in helping port galleon. will have a look at the latest version to familiarize my self over the next few days and post my thoughts.
> chris
>
>
>
> On 28 Dec 2009, at 16:12, Dan Wilson <sipa...@gmail.com> wrote:
>
> Hey Folks,
> We've been thinking through building out some useful Model-Glue based software for the community. Many developers want to get past the simplistic examples out there and learn how to solve harder problems with Model-Glue. We have 2 projects that we want to see happen in the first quarter of 2010. If you are interested in helping out on one of them, please email your interest to the group.
>
>
>
>
> Goal: Port Galleon Forums to Model-Glue
>
> Galleon Forums is a ColdFusion based forums application. A port to an earlier version of Model Glue was done by Isaac Dealey. We want to port the latest version of Galleon to MG 3 and add the following features:
>
> better theming supportprint friendly messagesmulti-homing (support for multiple forums in a single code base)as well as any other low hanging fruit gained by a refactor to MG3
>
>
> We will use this refactor to evolve some best practices about "Frameworktising" an existing application and also to evaluate new features for upcoming versions of Model-Glue.
>
>
> Who we Need: Developers, Testers, Forward Thinkers, Documenters, Current Galleon Users
> Goal: Build a Conference Management Application from Scratch
>
> We want to research building an application from scratch with Model-Glue. Important things to come out of this project are:How to use current Model-Glue 3 features for Rapid DevelopmentWhat we can improve about Model-Glue 3 for Rapid Development
>
> How to plan and structure a greenfield project for the fastest possible developmentBuild a great piece of Open Source software for the community to use and learn fromWho we Need: Developers, Testers, Forward Thinkers, Documenters, Conference Planners
Dan Wilson
Your email is very helpful... and I realize I might not have fully explained the point behind the fork. If we are able to incorporate MG 3 into Galleon and add some of these new features, Ray will let us commit this back into the Galleon project. Thus, the new version of Galleon would be a MG3 application (much like LighthousePro is)
So rather than a fork, which wouldn't be very helpful, we'd have a new platform for Galleon.
We can also take out parts of Galleon to use as actionpacks... like the registration portion and the security portion. Galleon is open source, so we can, with the proper attribution, look at enhancing Galleon as well as any parts that make sense for actionpacks.
I'd very much like to see a group of folks working on Actionpacks from a stragetic level. What are they? What should they be? How can MG be developed to make Actionpacks more useful/relevant?
From what I can tell, an 'actionpack' is really just including another MG.xmkl file. That is helpful and somewhat useful, I think we could make it even more useful and helpful with the right folks thinking about it. The Galleon project might be a good case to evaluate what an actionpack is, and could be.
DW
Chuck Savage
The editor, the administrator, the backend database, etc? You could easily write a first rank editor that was completely free of Galleon, and just call it for people's posts and comments.
I've seen several of Ray's projects, from Galleon, to BlogCFC, to his Wiki for RIAForge, each one apparently uses different editors, wouldn't it be handy to have one great editor that anyone could link to their project? In my opinion, that would be a great use of action packs/modules. It would need to allow as I think I've seen Ray post, a separate API that would parse text. Hope he's reading this and can pipe in, but it was something like the name's of the functions were the markup, or something like that.
--
Chuck Savage
http://SeaRisen.com
Lola Lee Beno
> I've seen several of Ray's projects, from Galleon, to BlogCFC, to his
> Wiki for RIAForge, each one apparently uses different editors,
> wouldn't it be handy to have one great editor that anyone could link
> to their project? In my opinion, that would be a great use of action
> packs/modules. It would need to allow as I think I've seen Ray post,
> a separate API that would parse text. Hope he's reading this and can
> pipe in, but it was something like the name's of the functions were
> the markup, or something like that.
Are you talking about WYSIWYM editors? I would like to have the ability
to replace with editors like MarkEdit
(http://github.com/tstone/jquery-markedit/). I really dislike TinyMCE
and I'm not in love with CKEditor, either.
denstar
> On 12/29/09 1:25 PM, Chuck Savage wrote:
>> I've seen several of Ray's projects, from Galleon, to BlogCFC, to his
>> Wiki for RIAForge, each one apparently uses different editors,
>> wouldn't it be handy to have one great editor that anyone could link
>> to their project? In my opinion, that would be a great use of action
>> packs/modules. It would need to allow as I think I've seen Ray post,
>> a separate API that would parse text. Hope he's reading this and can
>> pipe in, but it was something like the name's of the functions were
>> the markup, or something like that.
>
> Are you talking about WYSIWYM editors? I would like to have the ability
> to replace with editors like MarkEdit
> (http://github.com/tstone/jquery-markedit/). I really dislike TinyMCE
> and I'm not in love with CKEditor, either.
Sounds like what we need is a custom tag. :)
The obviously messy parts (JS location, for instance) could be
configured in MG somewhere I guess...
Ok, let us imagine we have a custom tag that works with {x} WYS*
editors-- the place where MG comes in is where?
A controller & a view I reckon? Maybe with stuff that lets us easily
add buttons (everybody needs custom buttons)... maybe has a variable
for plugging in file management... ?
Maybe what we need is a "widget" extension to the framework? For
configuring things like nifty editors or grids or bad-ass gauges?
Bah. However I roll this stuff around in my head, it leads me to
extending MG views to do more (like handle widgets).
Which tends to go against the idea of MG, sorta. ('course, I guess we
could just pin the widgets to the event, like we do with linkTo()?
Bottom line is that MG views won't work for other stuff anyways--
maybe it doesn't matter)
Anyways, for the moment, 'magine that we already have the "magic"
component that lets us use whatever editor (forget the widgets for a
second) the coder wants to use-- now what? How would we use this
component MG-style?
How are you imagining leveraging this editor in your MG application?
*that* is where things get interesting.
I think I'm leaning toward a widget/helper type deal, with default
implementations of editors and grids and whatnot.
Hrm. Whatever it is, it should fit in with scaffolding all slick-like, too.
:den
--
Happiness resides not in possessions, and not in gold, happiness
dwells in the soul.
Democritus
Dan Wilson
DW
--
Model-Glue Sites:
Home Page: http://www.model-glue.com
Documentation: http://docs.model-glue.com
Bug Tracker: http://bugs.model-glue.com
Blog: http://www.model-glue.com/blog
You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to model...@googlegroups.com
To unsubscribe from this group, send email to
model-glue+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en
Dennis Clark
- Move existing presentation logic to included views (using a standard structure var to pass all data from legacy templates to views).
- Introduce ColdSpring and convert existing model logic to ColdSpring beans.
- Introduce Model-Glue and convert legacy templates to event handlers with dedicated controllers.
- Refactor controllers to reduce duplication of controller code.
- Refactor views to reduce duplication of view code.
- Add event types to reduce duplication of event handler code.
- Refactor ColdSpring beans to provide more abstract interfaces and loosen dependencies with existing implementations.
- Identify actionpack candidates from portions of the application code.
- Select candidates and refactor into actionpacks.