Submitting Patches

[Michael Mullis]

With the move to git, what's going to be the best way to submit issues
and track patches?
The issues reported on http://code.google.com/p/erlyweb/ don't seem
to be moving
so I'm wondering what the future is for erlyweb.

Other thoughts?
/michael.

[Yariv Sadan]

I think the best way is through the mailing list. I generally accept
any useful patch.

Yariv

[Jared Kuolt]

GitHub is great about allowing forks of projects. I say create a fork,
then, when you're all ready to "submit" a patch, issue a pull request.

On Nov 13, 1:54 pm, "Yariv Sadan" <yarivsa...@gmail.com> wrote:
> I think the best way is through the mailing list. I generally accept
> any useful patch.
>
> Yariv
>
> On Thu, Nov 13, 2008 at 10:49 AM, Michael Mullis
>

> <mich...@mullistechnologies.com> wrote:
>
> > With the move to git, what's going to be the best way to submit issues
> > and track patches?

> > The issues reported onhttp://code.google.com/p/erlyweb/ don't seem

[Davide]

Hi all! :)

I've been hacking erlyweb, twoorl and noe lately introducing a lots of
changes that I find interesting for my projects.
In erlyweb I've:
- added support for erlang packages (http://www.erlang.org/doc/man/
packages.html) and changed
the compile procedure to use them;
- changed things so that the views would get access to the #arg
record (allowing erlyweb apps to be installed outside of /)
- refactored the normalized_appmoddata hack to yaws_arg (where I also
move get_app_root and get_url_prefix - as both depend only on the
remaining #arg fields)
- changed create_app() so that it would create the necessary boot
scripts and boilerplate compile functions that wrap the erlyweb ones
(a small abstraction is always nice) :)

I worked on getting twoorl and noe's boot code more similar so that
someone wanting to learn how to use erlyweb could migrate between
these projects more easily.
I also changed the twoorl start code so that it could be deployed as
an OTP application or a standalone Yaws server (I removed the
hardcoded configurations).

Ah, and of course, I have two branches of both twoorl and noe that use
my erlyweb+packages branch. :) (the twoorl one isn't ready for
publishing yet)

The best thing about supporting packages and non_root installations is
that this enables erlyweb webapps to run side by side on the same
server without any conflicts! :D
It's would be nice if these changes could get into erlyweb, but I'm
afraid that I haven't been very thoughtful about backwards
compatibility. :)
I also hacked together a replacement for YAPPS that should enable
newcomers to start using yaws more easily.

This is to much for a single post/mail/whatever so I'll just leave you
the links for my branches and let you take a look around.

My github account is: http://github.com/davide/
The README files in the various branches should contain all steps (and
links to required erlyweb branches) needed to get things working.

Feel free to take a look and forked it all up! :)

Cheers,
Davide :)

[tumi...@gmail.com]

Hello Yariv,
I need hi performance twiiter clone for my project.
I am intresdting in twoorl.
How I can help you?
may be I can test your software?

> > > > /michael.- Hide quoted text -
>
> - Show quoted text -

[Yariv Sadan]

Looks like you've done lots of good stuff. I'll check it out in more
detail and probably pull the changes into the main branch.

[Yariv Sadan]

Hi,

Free free to use Twoorl and contribute any enhancements you make back
to the project.

Cheers,
Yariv

[Davide Marquês]

On Thu, Dec 25, 2008 at 12:17 AM, Yariv Sadan <yariv...@gmail.com> wrote:
>
> Looks like you've done lots of good stuff. I'll check it out in more
> detail and probably pull the changes into the main branch.

I did mess up things quite a lot while I was learning how erlyweb
worked. Because of that I can only ensure that the latest versions (of
each branch) are fully functional (I've tested them with both twoorl
and noe, using Yawn - http://github.com/davide/yawn/tree/master - to
boot it up).

The erlyweb 'non_root_install' branch is still lacking a good way to
deploy javascript & css files based on templates (with the app_root
path replaced). Got ideas, ain't got time...
The 'packaged' branch is still in it's infancy but it has potential!
Using packages ensures that there won't be any code clashes so we can
think about filling up each webapp directory with its set of helper
modules/functions. Instead of having calls to erlyweb_html,
erlyweb_forms, erlyweb_util, yaws_arg, yaws_api we could create webapp
specific modules that would serve as layer to all those modules: a
"erlyweb api".
During an erlyweb upgrade instead of having to traverse all files to
fix names/args (I had to do a lot of that lately :P) the users could
simply update the "erlyweb api" modules or apply any needed witchery
on them to keep their webapp running.

If you need help sorting through my hacks just drop me a mail.

Cheers!
Davide :)