phpsqliteadmin-devel — phpSQLiteAdmin developer mailing list

[Phpsqliteadmin-devel] copy a cvs module

[Yves G. <yg...@mi...>]

Hi Guys,

argh, I spend half of the sunday afternoon trying to figure out how to 
copy a cvs module, e.g. from 
CVSROOT/phpsqliteadmin to CVSROOT/phpsqliteadmin2 but I failed 
miserably... Does someone have a clue how to do that?

Firman, If not then I suggest that you can use the checkout you have on 
your disk for your ideas, and when you feel like you wanna check 
something in, you can try to check it in directly as new module.... 
What do you think?


Regards,
Yves

-- 
Linux 2.6.12 #1 Sat Jul 9 23:28:04 CEST 2005 i686
 23:15:22 up  3:50,  1 user,  load average: 2.59, 0.99, 0.48

Re: [Phpsqliteadmin-devel] new cvs module

[Firman W. <fi...@gm...>]

On 7/11/05, Yves Glodt <yg...@mi...> wrote:
> Hi guys,
>=20
> I'm sorry I could not create the new module the weekend, due to
> extensive being-not-at-home.
> I should however be able to create it tonight.
>=20

Nevermind Yves, we not hurried. Just take your times.

> Yves
>=20

--=20
:: Never Dreamt Before ::
http://php.hm/~firman/
firman(@)php.net | firmanw(@)gmail.com

[Phpsqliteadmin-devel] new cvs module

[Yves G. <yg...@mi...>]

Hi guys,

I'm sorry I could not create the new module the weekend, due to 
extensive being-not-at-home.
I should however be able to create it tonight.

Yves

Re: [Phpsqliteadmin-devel] The API break

[Yves G. <yg...@mi...>]

Firman Wandayandi wrote:
>>>Ok what I will do then is I will try to create a new branch called
>>>phpsqliteadmin-tng (or phpsqliteadmin2) the weekend or later todaty and
>>>then you can start playing with that.
>>>
>>>
>>>>>I would suggest, if you want to do it, that we create a new module
>>>>>in cvs, and leave phpsla as it is now untouched, and start
>>>>>development of phpsla-ng in a new branch. Comments?
>>>>
>>>>I agree for that. But what is "phpsla-ng" exactly meant?
>>>
>>>I actually meant to write phpsla-tng which stands for "The next
>>>generation" ;-)
>>>
> 
> 
> Yeah, let's begin!


Ok, I will create a new cvs module asap, maybe later 2night or tomorrow.

Re: [Phpsqliteadmin-devel] The API break

[Firman W. <fi...@gm...>]

On 7/8/05, Felipe Lopes <ff...@gm...> wrote:
> I agree....Create a new module and lets check how this new generation com=
es out!
>=20
> Cheers
>=20
> Felipe Lopes
>=20
> On 7/8/05, Yves Glodt <yg...@mi...> wrote:
> > On Friday 08 July 2005 06:15, Firman Wandayandi wrote:
> > > On 7/8/05, Yves Glodt <yg...@mi...> wrote:
> > > > On Thursday 07 July 2005 11:30, Firman Wandayandi wrote:
> > > > > Ah yes, I'm forgot one thing. How if we use Smarty as template
> > > > > engine? So the UI should be change into templating system.
> > > >
> > > > I think that (and the planned move to another class) would almost
> > > > mean a complete rewrite.
> > > > I have no experience at all with smarty, so I can not comment on
> > > > it, but I have a question however: Would it help i18n'in phpsla?
> > >
> > > Yes, I has the method to handle it, with it phpsla will be support
> > > i18n. Actually I has the pattern of it, which is using Smarty and one
> > > plugin I named it "getLang" that provide string language management.
> > > getLang use one phpsla core class I named it "phpSLA_Language" ,
> > > phpSLA_Language is the backend for the language file, so if u choose
> > > "en" it's should be english, "id" should be indonesian, "br" should
> > > be brazillian portuguese and so on.
> >
> > Ok what I will do then is I will try to create a new branch called
> > phpsqliteadmin-tng (or phpsqliteadmin2) the weekend or later todaty and
> > then you can start playing with that.
> >
> > > > I would suggest, if you want to do it, that we create a new module
> > > > in cvs, and leave phpsla as it is now untouched, and start
> > > > development of phpsla-ng in a new branch. Comments?
> > >
> > > I agree for that. But what is "phpsla-ng" exactly meant?
> >
> > I actually meant to write phpsla-tng which stands for "The next
> > generation" ;-)
> >

Yeah, let's begin!

--=20
:: Never Dreamt Before ::
http://php.hm/~firman/
firman(@)php.net | firmanw(@)gmail.com

Re: [Phpsqliteadmin-devel] The API break

[Felipe L. <ff...@gm...>]

I agree....Create a new module and lets check how this new generation comes=
 out!

Cheers

Felipe Lopes

On 7/8/05, Yves Glodt <yg...@mi...> wrote:
> On Friday 08 July 2005 06:15, Firman Wandayandi wrote:
> > On 7/8/05, Yves Glodt <yg...@mi...> wrote:
> > > On Thursday 07 July 2005 11:30, Firman Wandayandi wrote:
> > > > Ah yes, I'm forgot one thing. How if we use Smarty as template
> > > > engine? So the UI should be change into templating system.
> > >
> > > I think that (and the planned move to another class) would almost
> > > mean a complete rewrite.
> > > I have no experience at all with smarty, so I can not comment on
> > > it, but I have a question however: Would it help i18n'in phpsla?
> >
> > Yes, I has the method to handle it, with it phpsla will be support
> > i18n. Actually I has the pattern of it, which is using Smarty and one
> > plugin I named it "getLang" that provide string language management.
> > getLang use one phpsla core class I named it "phpSLA_Language" ,
> > phpSLA_Language is the backend for the language file, so if u choose
> > "en" it's should be english, "id" should be indonesian, "br" should
> > be brazillian portuguese and so on.
>=20
> Ok what I will do then is I will try to create a new branch called
> phpsqliteadmin-tng (or phpsqliteadmin2) the weekend or later todaty and
> then you can start playing with that.
>=20
> > > I would suggest, if you want to do it, that we create a new module
> > > in cvs, and leave phpsla as it is now untouched, and start
> > > development of phpsla-ng in a new branch. Comments?
> >
> > I agree for that. But what is "phpsla-ng" exactly meant?
>=20
> I actually meant to write phpsla-tng which stands for "The next
> generation" ;-)
>=20
> > > regards,
> > > Yves
>=20
> --
> Linux 2.6.12 #1 Sun Jun 26 22:45:52 CEST 2005 i686
>  07:42:02 up 12:12,  0 users,  load average: 0.28, 0.15, 0.18
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar happen=
ing
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by H=
P,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> Phpsqliteadmin-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpsqliteadmin-devel
>

Re: [Phpsqliteadmin-devel] The API break

[Yves G. <yg...@mi...>]

On Friday 08 July 2005 06:15, Firman Wandayandi wrote:
> On 7/8/05, Yves Glodt <yg...@mi...> wrote:
> > On Thursday 07 July 2005 11:30, Firman Wandayandi wrote:
> > > Ah yes, I'm forgot one thing. How if we use Smarty as template
> > > engine? So the UI should be change into templating system.
> >
> > I think that (and the planned move to another class) would almost
> > mean a complete rewrite.
> > I have no experience at all with smarty, so I can not comment on
> > it, but I have a question however: Would it help i18n'in phpsla?
>
> Yes, I has the method to handle it, with it phpsla will be support
> i18n. Actually I has the pattern of it, which is using Smarty and one
> plugin I named it "getLang" that provide string language management.
> getLang use one phpsla core class I named it "phpSLA_Language" ,
> phpSLA_Language is the backend for the language file, so if u choose
> "en" it's should be english, "id" should be indonesian, "br" should
> be brazillian portuguese and so on.

Ok what I will do then is I will try to create a new branch called 
phpsqliteadmin-tng (or phpsqliteadmin2) the weekend or later todaty and 
then you can start playing with that.

> > I would suggest, if you want to do it, that we create a new module
> > in cvs, and leave phpsla as it is now untouched, and start
> > development of phpsla-ng in a new branch. Comments?
>
> I agree for that. But what is "phpsla-ng" exactly meant?

I actually meant to write phpsla-tng which stands for "The next 
generation" ;-)

> > regards,
> > Yves

-- 
Linux 2.6.12 #1 Sun Jun 26 22:45:52 CEST 2005 i686
 07:42:02 up 12:12,  0 users,  load average: 0.28, 0.15, 0.18

Re: [Phpsqliteadmin-devel] The API break

[Firman W. <fi...@gm...>]

On 7/8/05, Yves Glodt <yg...@mi...> wrote:
> On Thursday 07 July 2005 11:30, Firman Wandayandi wrote:
> > Ah yes, I'm forgot one thing. How if we use Smarty as template
> > engine? So the UI should be change into templating system.
>=20
> I think that (and the planned move to another class) would almost mean a
> complete rewrite.
> I have no experience at all with smarty, so I can not comment on it, but
> I have a question however: Would it help i18n'in phpsla?
>=20

Yes, I has the method to handle it, with it phpsla will be support
i18n. Actually I has the pattern of it, which is using Smarty and one
plugin I named it "getLang" that provide string language management.
getLang use one phpsla core class I named it "phpSLA_Language" ,
phpSLA_Language is the backend for the language file, so if u choose
"en" it's should be english, "id" should be indonesian, "br" should be
brazillian portuguese and so on.

> I would suggest, if you want to do it, that we create a new module in
> cvs, and leave phpsla as it is now untouched, and start development of
> phpsla-ng in a new branch. Comments?
>=20

I agree for that. But what is "phpsla-ng" exactly meant?

> regards,
> Yves
>=20

--=20
:: Never Dreamt Before ::
http://php.hm/~firman/
firman(@)php.net | firmanw(@)gmail.com

Re: [Phpsqliteadmin-devel] The API break

[Firman W. <fi...@gm...>]

Hi Felipe!

On 7/7/05, Felipe Lopes <ff...@gm...> wrote:
> Hi there folks!
>=20
> I myself don't like the idea of using Smarty....I just feel it is not
> necessary...
>=20
> What you guys think?
>=20

I think we can be more easy to maintaining the UI or design of the
interface if we use templating system method. Also switching from one
theme to another, other peoples may able to create a theme and submit
it to be use widely.

> Felipe Lopes
>=20
> On 7/7/05, Firman Wandayandi <fi...@gm...> wrote:
> > Ah yes, I'm forgot one thing. How if we use Smarty as template engine?
> > So the UI should be change into templating system.
> >
> > On 7/6/05, Firman Wandayandi <fi...@gm...> wrote:
> > > On 7/6/05, Yves Glodt <yg...@mi...> wrote:
> > > > Firman Wandayandi wrote:
> > > > > On 7/6/05, Yves Glodt <yg...@mi...> wrote:
> > > > >
> > > > >>Firman Wandayandi wrote:
> > > > >>
> > > > >>>Hi again guys,
> > > > >>
> > > > >>Hi,
> > > > >>
> > > > >>
> > > > >>>I'm currenty now working on phpsla core class, but the latest cv=
s
> > > > >>>codes seem doesn't meet with the pattern that I'm working on. I =
really
> > > > >>>really extreme break the API, that's ok for u guys?
> > > > >>
> > > > >>If it's worth it, and if phpsla will benefit from it, I see no pr=
oblem.
> > > > >>Are you going to fix phpsla to make it use the new api? :-)
> > > > >>
> > > > >
> > > > >
> > > > > The pattern I currently working is OO paradigm, to feet the
> > > > > requirements and useability, I hope is more benefit and profesion=
al
> > > > > than before. I think this will be good for the lifecycle in futur=
e
> > > > > use.
> > > > > Yes, maybe re-dev it. The new API has different logic and mechani=
sm. I
> > > > > think the new API will come with the brand new freshes codes mayb=
e all
> > > > > of codes.
> > > >
> > > > Ok I see. My only concern is that cvs should stay in a good shape, =
I
> > > > mean cvs should (apart of a more or less short period of time) stay
> > > > usable. If you need help in particular things, let us know.
> > > >
> > >
> > > Ah ok, I think I just need write the core classes for replacing the
> > > old class *forgot the name*, and then we can start to work on the
> > > phpsla interface, features and stuffs.
> > >
> > > > >>>Also I has designed the good looking project homepage for phpsla=
. I
> > > > >>>will commit it later.
> > > > >>
> > > > >>Any chance we could see it before :-)
> > > > >>
> > > > >
> > > > >
> > > > > I meant commit to this mailing list, if everyone like it, so rele=
ase it. :-D
> > > >
> > > > Ok cool, I'm just waiting for it :-)
> > > >
> > > > >>>Comments?
> > > > >>
> > > > >>Thanks for your engagement man,
> > > > >
> > > > >
> > > > > Nope, happy to help.
> > > > >
> > > > >
> > > > >>Yves
> > > > >>
> > > > >>
> > > > >>>Regards,
> > > > >>
> > > > >
> > > >
> > >
> >


--=20
:: Never Dreamt Before ::
http://php.hm/~firman/
firman(@)php.net | firmanw(@)gmail.com

Re: [Phpsqliteadmin-devel] The API break

[Yves G. <yg...@mi...>]

On Thursday 07 July 2005 11:30, Firman Wandayandi wrote:
> Ah yes, I'm forgot one thing. How if we use Smarty as template
> engine? So the UI should be change into templating system.

I think that (and the planned move to another class) would almost mean a 
complete rewrite.
I have no experience at all with smarty, so I can not comment on it, but 
I have a question however: Would it help i18n'in phpsla?

I would suggest, if you want to do it, that we create a new module in 
cvs, and leave phpsla as it is now untouched, and start development of 
phpsla-ng in a new branch. Comments?

regards,
Yves

-- 
Linux 2.6.12 #1 Sun Jun 26 22:45:52 CEST 2005 i686
 19:45:04 up 15 min,  0 users,  load average: 1.10, 0.73, 0.45

Re: [Phpsqliteadmin-devel] The API break

[Felipe L. <ff...@gm...>]

Hi there folks!

I myself don't like the idea of using Smarty....I just feel it is not
necessary...

What you guys think?

Felipe Lopes

On 7/7/05, Firman Wandayandi <fi...@gm...> wrote:
> Ah yes, I'm forgot one thing. How if we use Smarty as template engine?
> So the UI should be change into templating system.
>=20
> On 7/6/05, Firman Wandayandi <fi...@gm...> wrote:
> > On 7/6/05, Yves Glodt <yg...@mi...> wrote:
> > > Firman Wandayandi wrote:
> > > > On 7/6/05, Yves Glodt <yg...@mi...> wrote:
> > > >
> > > >>Firman Wandayandi wrote:
> > > >>
> > > >>>Hi again guys,
> > > >>
> > > >>Hi,
> > > >>
> > > >>
> > > >>>I'm currenty now working on phpsla core class, but the latest cvs
> > > >>>codes seem doesn't meet with the pattern that I'm working on. I re=
ally
> > > >>>really extreme break the API, that's ok for u guys?
> > > >>
> > > >>If it's worth it, and if phpsla will benefit from it, I see no prob=
lem.
> > > >>Are you going to fix phpsla to make it use the new api? :-)
> > > >>
> > > >
> > > >
> > > > The pattern I currently working is OO paradigm, to feet the
> > > > requirements and useability, I hope is more benefit and profesional
> > > > than before. I think this will be good for the lifecycle in future
> > > > use.
> > > > Yes, maybe re-dev it. The new API has different logic and mechanism=
. I
> > > > think the new API will come with the brand new freshes codes maybe =
all
> > > > of codes.
> > >
> > > Ok I see. My only concern is that cvs should stay in a good shape, I
> > > mean cvs should (apart of a more or less short period of time) stay
> > > usable. If you need help in particular things, let us know.
> > >
> >
> > Ah ok, I think I just need write the core classes for replacing the
> > old class *forgot the name*, and then we can start to work on the
> > phpsla interface, features and stuffs.
> >
> > > >>>Also I has designed the good looking project homepage for phpsla. =
I
> > > >>>will commit it later.
> > > >>
> > > >>Any chance we could see it before :-)
> > > >>
> > > >
> > > >
> > > > I meant commit to this mailing list, if everyone like it, so releas=
e it. :-D
> > >
> > > Ok cool, I'm just waiting for it :-)
> > >
> > > >>>Comments?
> > > >>
> > > >>Thanks for your engagement man,
> > > >
> > > >
> > > > Nope, happy to help.
> > > >
> > > >
> > > >>Yves
> > > >>
> > > >>
> > > >>>Regards,
> > > >>
> > > >
> > >
> >
>=20
> --
> :: Never Dreamt Before ::
> http://php.hm/~firman/
> firman(@)php.net | firmanw(@)gmail.com
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&opclick
> _______________________________________________
> Phpsqliteadmin-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpsqliteadmin-devel
>

Re: [Phpsqliteadmin-devel] The API break

[Firman W. <fi...@gm...>]

Ah yes, I'm forgot one thing. How if we use Smarty as template engine?
So the UI should be change into templating system.

On 7/6/05, Firman Wandayandi <fi...@gm...> wrote:
> On 7/6/05, Yves Glodt <yg...@mi...> wrote:
> > Firman Wandayandi wrote:
> > > On 7/6/05, Yves Glodt <yg...@mi...> wrote:
> > >
> > >>Firman Wandayandi wrote:
> > >>
> > >>>Hi again guys,
> > >>
> > >>Hi,
> > >>
> > >>
> > >>>I'm currenty now working on phpsla core class, but the latest cvs
> > >>>codes seem doesn't meet with the pattern that I'm working on. I real=
ly
> > >>>really extreme break the API, that's ok for u guys?
> > >>
> > >>If it's worth it, and if phpsla will benefit from it, I see no proble=
m.
> > >>Are you going to fix phpsla to make it use the new api? :-)
> > >>
> > >
> > >
> > > The pattern I currently working is OO paradigm, to feet the
> > > requirements and useability, I hope is more benefit and profesional
> > > than before. I think this will be good for the lifecycle in future
> > > use.
> > > Yes, maybe re-dev it. The new API has different logic and mechanism. =
I
> > > think the new API will come with the brand new freshes codes maybe al=
l
> > > of codes.
> >
> > Ok I see. My only concern is that cvs should stay in a good shape, I
> > mean cvs should (apart of a more or less short period of time) stay
> > usable. If you need help in particular things, let us know.
> >
>=20
> Ah ok, I think I just need write the core classes for replacing the
> old class *forgot the name*, and then we can start to work on the
> phpsla interface, features and stuffs.
>=20
> > >>>Also I has designed the good looking project homepage for phpsla. I
> > >>>will commit it later.
> > >>
> > >>Any chance we could see it before :-)
> > >>
> > >
> > >
> > > I meant commit to this mailing list, if everyone like it, so release =
it. :-D
> >
> > Ok cool, I'm just waiting for it :-)
> >
> > >>>Comments?
> > >>
> > >>Thanks for your engagement man,
> > >
> > >
> > > Nope, happy to help.
> > >
> > >
> > >>Yves
> > >>
> > >>
> > >>>Regards,
> > >>
> > >
> >
>=20

--=20
:: Never Dreamt Before ::
http://php.hm/~firman/
firman(@)php.net | firmanw(@)gmail.com

Re: [Phpsqliteadmin-devel] The API break

[Firman W. <fi...@gm...>]

On 7/6/05, Yves Glodt <yg...@mi...> wrote:
> Firman Wandayandi wrote:
> > On 7/6/05, Yves Glodt <yg...@mi...> wrote:
> >
> >>Firman Wandayandi wrote:
> >>
> >>>Hi again guys,
> >>
> >>Hi,
> >>
> >>
> >>>I'm currenty now working on phpsla core class, but the latest cvs
> >>>codes seem doesn't meet with the pattern that I'm working on. I really
> >>>really extreme break the API, that's ok for u guys?
> >>
> >>If it's worth it, and if phpsla will benefit from it, I see no problem.
> >>Are you going to fix phpsla to make it use the new api? :-)
> >>
> >
> >
> > The pattern I currently working is OO paradigm, to feet the
> > requirements and useability, I hope is more benefit and profesional
> > than before. I think this will be good for the lifecycle in future
> > use.
> > Yes, maybe re-dev it. The new API has different logic and mechanism. I
> > think the new API will come with the brand new freshes codes maybe all
> > of codes.
>=20
> Ok I see. My only concern is that cvs should stay in a good shape, I
> mean cvs should (apart of a more or less short period of time) stay
> usable. If you need help in particular things, let us know.
>=20

Ah ok, I think I just need write the core classes for replacing the
old class *forgot the name*, and then we can start to work on the
phpsla interface, features and stuffs.

> >>>Also I has designed the good looking project homepage for phpsla. I
> >>>will commit it later.
> >>
> >>Any chance we could see it before :-)
> >>
> >
> >
> > I meant commit to this mailing list, if everyone like it, so release it=
. :-D
>=20
> Ok cool, I'm just waiting for it :-)
>=20
> >>>Comments?
> >>
> >>Thanks for your engagement man,
> >
> >
> > Nope, happy to help.
> >
> >
> >>Yves
> >>
> >>
> >>>Regards,
> >>
> >
>=20

--=20
:: Never Dreamt Before ::
http://php.hm/~firman/
firman(@)php.net | firmanw(@)gmail.com

Re: [Phpsqliteadmin-devel] The API break

[Yves G. <yg...@mi...>]

Firman Wandayandi wrote:
> On 7/6/05, Yves Glodt <yg...@mi...> wrote:
> 
>>Firman Wandayandi wrote:
>>
>>>Hi again guys,
>>
>>Hi,
>>
>>
>>>I'm currenty now working on phpsla core class, but the latest cvs
>>>codes seem doesn't meet with the pattern that I'm working on. I really
>>>really extreme break the API, that's ok for u guys?
>>
>>If it's worth it, and if phpsla will benefit from it, I see no problem.
>>Are you going to fix phpsla to make it use the new api? :-)
>>
> 
> 
> The pattern I currently working is OO paradigm, to feet the
> requirements and useability, I hope is more benefit and profesional
> than before. I think this will be good for the lifecycle in future
> use.
> Yes, maybe re-dev it. The new API has different logic and mechanism. I
> think the new API will come with the brand new freshes codes maybe all
> of codes.

Ok I see. My only concern is that cvs should stay in a good shape, I 
mean cvs should (apart of a more or less short period of time) stay 
usable. If you need help in particular things, let us know.

>>>Also I has designed the good looking project homepage for phpsla. I
>>>will commit it later.
>>
>>Any chance we could see it before :-)
>>
> 
> 
> I meant commit to this mailing list, if everyone like it, so release it. :-D

Ok cool, I'm just waiting for it :-)

>>>Comments?
>>
>>Thanks for your engagement man,
> 
> 
> Nope, happy to help.
> 
> 
>>Yves
>>
>>
>>>Regards,
>>
> 

Re: [Phpsqliteadmin-devel] The API break

[Firman W. <fi...@gm...>]

On 7/6/05, Yves Glodt <yg...@mi...> wrote:
> Firman Wandayandi wrote:
> > Hi again guys,
>=20
> Hi,
>=20
> > I'm currenty now working on phpsla core class, but the latest cvs
> > codes seem doesn't meet with the pattern that I'm working on. I really
> > really extreme break the API, that's ok for u guys?
>=20
> If it's worth it, and if phpsla will benefit from it, I see no problem.
> Are you going to fix phpsla to make it use the new api? :-)
>=20

The pattern I currently working is OO paradigm, to feet the
requirements and useability, I hope is more benefit and profesional
than before. I think this will be good for the lifecycle in future
use.
Yes, maybe re-dev it. The new API has different logic and mechanism. I
think the new API will come with the brand new freshes codes maybe all
of codes.

> > Also I has designed the good looking project homepage for phpsla. I
> > will commit it later.
>=20
> Any chance we could see it before :-)
>=20

I meant commit to this mailing list, if everyone like it, so release it. :-=
D

> > Comments?
>=20
> Thanks for your engagement man,

Nope, happy to help.

> Yves
>=20
> > Regards,
>=20

--=20
:: Never Dreamt Before ::
http://php.hm/~firman/
firman(@)php.net | firmanw(@)gmail.com

Re: [Phpsqliteadmin-devel] The API break

[Yves G. <yg...@mi...>]

Firman Wandayandi wrote:
> Hi again guys,

Hi,

> I'm currenty now working on phpsla core class, but the latest cvs
> codes seem doesn't meet with the pattern that I'm working on. I really
> really extreme break the API, that's ok for u guys?

If it's worth it, and if phpsla will benefit from it, I see no problem.
Are you going to fix phpsla to make it use the new api? :-)

> Also I has designed the good looking project homepage for phpsla. I
> will commit it later.

Any chance we could see it before :-)

> Comments?

Thanks for your engagement man,
Yves

> Regards,

[Phpsqliteadmin-devel] The API break

[Firman W. <fi...@gm...>]

Hi again guys,

I'm currenty now working on phpsla core class, but the latest cvs
codes seem doesn't meet with the pattern that I'm working on. I really
really extreme break the API, that's ok for u guys?

Also I has designed the good looking project homepage for phpsla. I
will commit it later.

Comments?

Regards,
--=20
:: Never Dreamt Before ::
http://php.hm/~firman/
firman(@)php.net | firmanw(@)gmail.com

Re: [Phpsqliteadmin-devel] Another SQLite documentation/manual

[Yves G. <yg...@mi...>]

On Monday 04 July 2005 10:11, Firman Wandayandi wrote:
> Hi Guys.

Hi,

> Any SQLite documentation/manual out there? There's not enough with
> the official documentation for me, I need more docs for exploring
> SQLite.

I found this quite useful, as it's part of the official doc you have it 
already... Sorry I have no more :-(

regards,
Yves


> Thanks.

-- 
Linux 2.6.12 #1 Sun Jun 26 22:45:52 CEST 2005 i686
 23:01:32 up  1:32,  0 users,  load average: 2.13, 1.44, 0.93

[Phpsqliteadmin-devel] Another SQLite documentation/manual

[Firman W. <fi...@gm...>]

Hi Guys.

Any SQLite documentation/manual out there? There's not enough with the
official documentation for me, I need more docs for exploring SQLite.

Thanks.
--=20
Firman Wandayandi :: Never Dreamt Before
< http://php.hm/~firman/ | firman(@)php.net | firmanw(@)gmail.com >

Re: [Phpsqliteadmin-devel] [LOGO] call for vote

[Steve D. <st...@wo...>]

Robin Bowes wrote:

> One thing occurs to me (as it does for the phpPgAdmin project) and that 
> is why are you not riding on the back of phpMyAdmin and simply replacing 
> the DB-specific stuff? Surely, that would be a simpler approach? Or am I 
> being too simplistic?

I wish it were that easy.  I actually started doing that, but there are 
some major differences.

One, being that no matter what frontend you're writing, you're going to 
be pulling a lot of metadata from the databases.  The queries are going 
to be absolutely different.  In SQLite it's something like querying 
master_database or something like that.. you can look at sqlite.org and 
it has some docs on how to pull the stuff out.

Well, there's other reasons, but they boil down to the same concept -- 
the queries are just too different because of how you're hitting system 
data, eventually.

It would be easy, however, to copy the layout and display of pma, I 
think.  There are a lot of HARD features to copy everything straight 
over though, and you would need to work on a good backend so you know 
how to go about doing that stuff.  For example, if someone wants to 
delete a row, and there's no primary key, how do you delete the right 
one?  Well, there's a couple of ways ... you could say "DELETE FROM 
table_name WHERE field1 = $field1, field2 = $field2, " etc ... or I 
think pma actually does something like "DELETE FROM table LIMIT 1 OFFSET 
$offset" where $offset is known based on the page you're displaying 
(display 30, start at offset 30), then the row number (delete row 5, so 
offset 30 + 5 .. ).  Pretty, smart actually.

The problem I keep running into when hacking on psa is whether to start 
from scratch and replicate the look/feel/functionality of pma or mangle 
the current release and try to mold it into something else.  The first 
option is fun until you realize you quickly have to have some kind of 
class to make the common functions easy, and the second one is 
entertaining until you realize you're hacking with frames and the layout 
can confuse you.

If I had to start all over again, I would just start building one from 
scratch -- not replicating pma in *every* respect, but instead starting 
with the very basic functions: display the databases, select a database, 
display the table metadata, display the table, add a query form.  And 
just go from there.  Things are much, much easier to work with once you 
have something where you can just *browse* your databases + data to see 
what you're working with, so you don't go quite insane. :)  I'm speaking 
partially from experience since I'm using sql server 2000 at work, and I 
had to develop a small frontend for it just so I wouldn't go insane. 
Building those basics is actually really, really easy.  I've even got it 
  so I can export any query to CSV which is cool.  But it's when you get 
down to the nitty-gritty like creating tables in a frontend, and 
deleting rows and stuff like that that it gets tough.

So, I don't really have any advice on how to go about building a db 
frontend, really.  Other than keep it simple, add features slowly, and 
write some functions and maybe a class to help you do the simple things.

My only suggestion would be to layout what features you want it to have, 
argue about how to implement it, make a function so it's easy to do, and 
then anticipate any errors that might come along and work around those, 
and get it working.  Worry about design, layout and look and feel last. 
  The important thing is to get the functionality coded and working and 
stable first.  Who cares if your frontend is a two framed html horror -- 
as long as it works, you can always go back later and add some css magic.

The great thing about writing a frontend to a dba is that 1) you get to 
learn it's possibilties and limitations REALLY quickly and 2) you don't 
have to manage everything command line anymore.

Anyway, I shouldnt say too much more, since I never really contribute 
anything.  Someday, I hope. :)

Steve

p.s. and if anyones interested, I can pass along some screenshots of my 
mssql frontend if you want to see what I'm talking about.

Re: [Phpsqliteadmin-devel] [LOGO] call for vote

[Robin B. <rob...@ro...>]

Yves Glodt wrote:

> Version 0.2 (the last release) is usable, but basic. All the implemented 
> features work. There has been some more work done after, but not enough 
> to justify a new release.
> 
> Check out cvs if you wanna see the current state. I plan to do more work   
> on it soon, the logo will of course also be added then...

Yves,

Thanks for the update.

One thing occurs to me (as it does for the phpPgAdmin project) and that 
is why are you not riding on the back of phpMyAdmin and simply replacing 
the DB-specific stuff? Surely, that would be a simpler approach? Or am I 
being too simplistic?

R.

-- 
http://robinbowes.com

If a man speaks in a forest,
and his wife's not there,
is he still wrong?

Re: [Phpsqliteadmin-devel] [LOGO] call for vote

[Yves G. <yg...@mi...>]

On Tuesday 24 May 2005 16:29, Robin Bowes wrote:
> Firman Wandayandi wrote:
> > I think we must vote which logo will be use for. so which one?
>
> +1 for #3

Hi,

> PS. Is phpSQLiteAdmin usable yet (I subscribed to this list at a very
> early stage of development and haven't tried it recently)

Version 0.2 (the last release) is usable, but basic. All the implemented 
features work. There has been some more work done after, but not enough 
to justify a new release.

Check out cvs if you wanna see the current state. I plan to do more work   
on it soon, the logo will of course also be added then...


regards,
Yves

> R.

-- 
Linux 2.6.11.10 #1 Wed May 18 17:50:55 CEST 2005 i686
 17:33:03 up  4:44,  1 user,  load average: 1.00, 0.57, 0.58

Re: [Phpsqliteadmin-devel] [LOGO] call for vote

[Robin B. <rob...@ro...>]

Firman Wandayandi wrote:
> I think we must vote which logo will be use for. so which one?

+1 for #3

PS. Is phpSQLiteAdmin usable yet (I subscribed to this list at a very 
early stage of development and haven't tried it recently)

R.

-- 
http://robinbowes.com

If a man speaks in a forest,
and his wife's not there,
is he still wrong?

Re: [Phpsqliteadmin-devel] [LOGO] call for vote

[Yves G. <yg...@mi...>]

On Sunday 22 May 2005 19:48, Firman Wandayandi wrote:
> I think we must vote which logo will be use for. so which one?
>
> me: +1 for #3

me the same, very good work!
:-)

Yves

=2D-=20
Linux 2.6.11.10 #1 Wed May 18 17:50:55 CEST 2005 i686
 10:29:07 up 25 min,  1 user,  load average: 1.32, 0.90, 0.83

Re: [Phpsqliteadmin-devel] [LOGO] call for vote

[Witold C. <wit...@pr...>]

#3!

Best regards,
Witold

----- Original Message ----- 
From: "Firman Wandayandi" <fi...@gm...>
To: "PHPSQLiteAdmin-DEV" <php...@li...>
Sent: Sunday, May 22, 2005 7:48 PM
Subject: [Phpsqliteadmin-devel] [LOGO] call for vote


I think we must vote which logo will be use for. so which one?

me: +1 for #3
-- 
Firman Wandayandi < firman(@)php.net | firmanw(@)gmail.com > : Never
Dreamt Before