1C: ਐਂਟਰਪ੍ਰਾਈਜ਼ ਡਿਵੈਲਪਮੈਂਟ ਟੂਲਸ ਲਈ ਇੱਕ ਤਕਨਾਲੋਜੀ ਪਲੇਟਫਾਰਮ ਵਜੋਂ ਗ੍ਰਹਿਣ

ਸ਼ਾਇਦ, eclipse ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਜਾਣ-ਪਛਾਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਲੋਕ Eclipse ਤੋਂ ਜਾਣੂ ਹਨ Eclipse Java ਡਿਵੈਲਪਮੈਂਟ ਟੂਲਸ (ਜੇ.ਡੀ.ਟੀ). ਇਹ ਇਹ ਪ੍ਰਸਿੱਧ ਓਪਨ-ਸਰੋਤ Java IDE ਹੈ ਜਿਸ ਨੂੰ ਜ਼ਿਆਦਾਤਰ ਡਿਵੈਲਪਰ "ਐਕਲਿਪਸ" ਸ਼ਬਦ ਨਾਲ ਜੋੜਦੇ ਹਨ। ਹਾਲਾਂਕਿ, ਇਕਲਿਪਸ ਡਿਵੈਲਪਮੈਂਟ ਟੂਲਸ (ਐਕਲਿਪਸ ਪਲੇਟਫਾਰਮ) ਨੂੰ ਏਕੀਕ੍ਰਿਤ ਕਰਨ ਲਈ ਇੱਕ ਐਕਸਟੈਂਸੀਬਲ ਪਲੇਟਫਾਰਮ ਹੈ, ਅਤੇ ਇਸਦੇ ਅਧਾਰ 'ਤੇ ਬਣਾਏ ਗਏ ਕਈ IDE, JDT ਸਮੇਤ। Eclipse Eclipse ਪ੍ਰੋਜੈਕਟ, ਇੱਕ ਉੱਚ-ਪੱਧਰੀ ਪ੍ਰੋਜੈਕਟ ਜੋ Eclipse ਪਲੇਟਫਾਰਮ ਅਤੇ JDT, ਅਤੇ Eclipse SDK ਦੇ ਵਿਕਾਸ ਦਾ ਤਾਲਮੇਲ ਕਰਦਾ ਹੈ, ਉਸ ਵਿਕਾਸ ਦਾ ਨਤੀਜਾ ਹੈ। ਅੰਤ ਵਿੱਚ, ਈਲੈਪਸ ਇੱਕ ਓਪਨ-ਸੋਰਸ ਫਾਊਂਡੇਸ਼ਨ ਹੈ ਜਿਸ ਵਿੱਚ ਪ੍ਰੋਜੈਕਟਾਂ ਦੇ ਇੱਕ ਵਿਸ਼ਾਲ ਸਮੂਹ ਹਨ, ਜੋ ਕਿ ਸਾਰੇ ਜਾਵਾ ਵਿੱਚ ਨਹੀਂ ਲਿਖੇ ਗਏ ਹਨ ਜਾਂ ਵਿਕਾਸ ਸਾਧਨਾਂ ਨਾਲ ਸਬੰਧਤ ਨਹੀਂ ਹਨ (ਉਦਾਹਰਨ ਲਈ, ਪ੍ਰੋਜੈਕਟ Eclipse IoT и ਗ੍ਰਹਿਣ ਵਿਗਿਆਨ). ਗ੍ਰਹਿਣ ਦੀ ਦੁਨੀਆ ਬਹੁਤ ਵੰਨ-ਸੁਵੰਨੀ ਹੈ।

ਇਸ ਲੇਖ ਵਿੱਚ, ਜੋ ਕਿ ਕੁਦਰਤ ਵਿੱਚ ਸੰਖੇਪ ਜਾਣਕਾਰੀ ਹੈ, ਅਸੀਂ ਏਕੀਕ੍ਰਿਤ ਵਿਕਾਸ ਸਾਧਨਾਂ ਨੂੰ ਬਣਾਉਣ ਲਈ ਇੱਕ ਪਲੇਟਫਾਰਮ ਦੇ ਰੂਪ ਵਿੱਚ ਈਲੈਪਸ ਆਰਕੀਟੈਕਚਰ ਦੀਆਂ ਕੁਝ ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਨੂੰ ਦੇਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗੇ ਅਤੇ ਤਕਨਾਲੋਜੀ ਦੀ ਬੁਨਿਆਦ ਬਣਾਉਣ ਵਾਲੇ ਈਲੈਪਸ ਕੰਪੋਨੈਂਟਸ ਦਾ ਸ਼ੁਰੂਆਤੀ ਵਿਚਾਰ ਦੇਵਾਂਗੇ। "ਨਵਾਂ ਕੌਨਫਿਗਰੇਟਰ" 1C ਲਈ ਪਲੇਟਫਾਰਮ: ਐਂਟਰਪ੍ਰਾਈਜ਼। 1C: ਐਂਟਰਪ੍ਰਾਈਜ਼ ਡਿਵੈਲਪਮੈਂਟ ਟੂਲ. ਬੇਸ਼ੱਕ, ਅਜਿਹੀ ਸਮੀਖਿਆ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਸਤਹੀ ਅਤੇ ਸੀਮਤ ਹੋਵੇਗੀ, ਜਿਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹੈ ਕਿਉਂਕਿ ਅਸੀਂ ਟੀਚਾ ਦਰਸ਼ਕ ਵਜੋਂ ਨਾ ਸਿਰਫ ਇਕਲਿਪਸ ਡਿਵੈਲਪਰਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰ ਰਹੇ ਹਾਂ। ਹਾਲਾਂਕਿ, ਅਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹਾਂ ਕਿ ਤਜਰਬੇਕਾਰ ਈਲੈਪਸ ਡਿਵੈਲਪਰ ਵੀ ਲੇਖ ਵਿੱਚ ਦਿਲਚਸਪ ਜਾਣਕਾਰੀ ਲੱਭਣ ਦੇ ਯੋਗ ਹੋਣਗੇ. ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ "ਐਕਲਿਪਸ ਦੇ ਭੇਦ" ਵਿੱਚੋਂ ਇੱਕ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ, ਇੱਕ ਮੁਕਾਬਲਤਨ ਨਵਾਂ ਅਤੇ ਘੱਟ-ਜਾਣਿਆ ਪ੍ਰੋਜੈਕਟ ਹੱਥੀਂ ਗ੍ਰਹਿਣ ਕਰੋ, ਜੋ ਕਿ 1C ਦੁਆਰਾ ਸਥਾਪਿਤ ਅਤੇ ਸਮਰਥਿਤ ਸੀ।

ਈਲੈਪਸ ਆਰਕੀਟੈਕਚਰ ਨਾਲ ਜਾਣ-ਪਛਾਣ

ਆਓ ਪਹਿਲਾਂ ਉਦਾਹਰਣ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਈਲੈਪਸ ਆਰਕੀਟੈਕਚਰ ਦੇ ਕੁਝ ਆਮ ਪਹਿਲੂਆਂ 'ਤੇ ਨਜ਼ਰ ਮਾਰੀਏ Eclipse Java ਵਿਕਾਸ ਸਾਧਨ (JDT)। ਇੱਕ ਉਦਾਹਰਣ ਵਜੋਂ ਜੇਡੀਟੀ ਦੀ ਚੋਣ ਅਚਾਨਕ ਨਹੀਂ ਹੈ। Eclipse ਵਿੱਚ ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ ਇਹ ਪਹਿਲਾ ਏਕੀਕ੍ਰਿਤ ਵਿਕਾਸ ਵਾਤਾਵਰਨ ਹੈ। ਹੋਰ *DT Eclipse ਪ੍ਰੋਜੈਕਟ, ਜਿਵੇਂ ਕਿ Eclipse C/C++ ਡਿਵੈਲਪਮੈਂਟ ਟੂਲਿੰਗ (CDT), ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਬਣਾਇਆ ਗਿਆ ਸੀ ਅਤੇ JDT ਤੋਂ ਮੂਲ ਆਰਕੀਟੈਕਚਰਲ ਸਿਧਾਂਤ ਅਤੇ ਵਿਅਕਤੀਗਤ ਸਰੋਤ ਕੋਡ ਦੇ ਟੁਕੜੇ ਦੋਵੇਂ ਉਧਾਰ ਲਏ ਗਏ ਸਨ। JDT ਵਿੱਚ ਨਿਰਧਾਰਿਤ ਆਰਕੀਟੈਕਚਰ ਦੇ ਮੂਲ ਤੱਤ ਅੱਜ ਤੱਕ Eclipse ਪਲੇਟਫਾਰਮ ਦੇ ਸਿਖਰ 'ਤੇ ਬਣੇ ਲਗਭਗ ਕਿਸੇ ਵੀ IDE ਲਈ ਢੁਕਵੇਂ ਹਨ, ਜਿਸ ਵਿੱਚ 1C:Enterprise Development Tools ਸ਼ਾਮਲ ਹਨ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਨੋਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ Eclipse ਇੱਕ ਕਾਫ਼ੀ ਸਪਸ਼ਟ ਆਰਕੀਟੈਕਚਰਲ ਲੇਅਰਿੰਗ ਦੁਆਰਾ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ, ਖਾਸ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਨੂੰ ਸਮਰਥਨ ਦੇਣ ਲਈ ਤਿਆਰ ਕੀਤੀ ਗਈ ਕਾਰਜਸ਼ੀਲਤਾ ਤੋਂ ਭਾਸ਼ਾ-ਸੁਤੰਤਰ ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ ਵੱਖ ਕਰਨ ਦੇ ਨਾਲ, ਅਤੇ ਸੰਬੰਧਿਤ ਹਿੱਸਿਆਂ ਤੋਂ UI- ਸੁਤੰਤਰ "ਕੋਰ" ਭਾਗਾਂ ਨੂੰ ਵੱਖ ਕਰਨਾ। ਸਹਿਯੋਗੀ ਯੂਜ਼ਰ ਇੰਟਰਫੇਸ ਦੇ ਨਾਲ.

ਇਸ ਤਰ੍ਹਾਂ, ਇਕਲਿਪਸ ਪਲੇਟਫਾਰਮ ਇੱਕ ਆਮ, ਭਾਸ਼ਾ-ਸੁਤੰਤਰ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਜਾਵਾ ਡਿਵੈਲਪਮੈਂਟ ਟੂਲ ਇੱਕ ਪੂਰੀ ਵਿਸ਼ੇਸ਼ਤਾ ਵਾਲੇ Java IDE ਨੂੰ Eclipse ਵਿੱਚ ਜੋੜਦੇ ਹਨ। ਈਲੈਪਸ ਪਲੇਟਫਾਰਮ ਅਤੇ ਜੇਡੀਟੀ ਦੋਨਾਂ ਵਿੱਚ ਕਈ ਭਾਗ ਹੁੰਦੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ UI-ਸੁਤੰਤਰ “ਕੋਰ” ਜਾਂ ਇੱਕ UI ਪਰਤ (ਚਿੱਤਰ 1) ਨਾਲ ਸਬੰਧਤ ਹੈ।

ਚੌਲ. 1. ਈਲੈਪਸ ਪਲੇਟਫਾਰਮ ਅਤੇ ਜੇ.ਡੀ.ਟੀ

ਆਓ ਈਲੈਪਸ ਪਲੇਟਫਾਰਮ ਦੇ ਮੁੱਖ ਭਾਗਾਂ ਦੀ ਸੂਚੀ ਕਰੀਏ:

• ਰਨਟਾਈਮ — ਪਲੱਗਇਨ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਗ੍ਰਹਿਣ ਨੂੰ ਇੱਕ ਮਾਡਿਊਲਰ ਆਰਕੀਟੈਕਚਰ ਦੁਆਰਾ ਦਰਸਾਇਆ ਗਿਆ ਹੈ। ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ, ਈਲੈਪਸ "ਐਕਸਟੈਂਸ਼ਨ ਪੁਆਇੰਟਾਂ" ਅਤੇ "ਐਕਸਟੈਂਸ਼ਨਾਂ" ਦਾ ਸੰਗ੍ਰਹਿ ਹੈ।
• ਵਰਕਸਪੇਸ - ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਪ੍ਰੋਜੈਕਟਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ। ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਫੋਲਡਰ ਅਤੇ ਫਾਈਲਾਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਸਿੱਧੇ ਫਾਈਲ ਸਿਸਟਮ ਨਾਲ ਮੈਪ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
• ਸਟੈਂਡਰਡ ਵਿਜੇਟ ਟੂਲਕਿੱਟ (SWT) - ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨਾਲ ਏਕੀਕ੍ਰਿਤ ਬੁਨਿਆਦੀ ਉਪਭੋਗਤਾ ਇੰਟਰਫੇਸ ਤੱਤ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ.
• ਜੇਫੇਸ - SWT ਦੇ ਸਿਖਰ 'ਤੇ ਬਣੇ ਕਈ UI ਫਰੇਮਵਰਕ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
• ਵਰਕਬੈਂਚ - ਈਲੈਪਸ UI ਪੈਰਾਡਾਈਮ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ: ਸੰਪਾਦਕ, ਦ੍ਰਿਸ਼, ਦ੍ਰਿਸ਼ਟੀਕੋਣ।

ਇਹ ਕਿਹਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਈਲੈਪਸ ਪਲੇਟਫਾਰਮ ਡੀਬੱਗ, ਤੁਲਨਾ, ਖੋਜ ਅਤੇ ਟੀਮ ਸਮੇਤ ਏਕੀਕ੍ਰਿਤ ਵਿਕਾਸ ਸਾਧਨਾਂ ਨੂੰ ਬਣਾਉਣ ਲਈ ਕਈ ਹੋਰ ਉਪਯੋਗੀ ਭਾਗ ਵੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। JFace ਟੈਕਸਟ ਦਾ ਵਿਸ਼ੇਸ਼ ਜ਼ਿਕਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ - ਸਰੋਤ ਕੋਡ ਦੇ "ਸਮਾਰਟ ਸੰਪਾਦਕ" ਬਣਾਉਣ ਦਾ ਆਧਾਰ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਇਸ ਲੇਖ ਦੇ ਦਾਇਰੇ ਵਿੱਚ ਇਹਨਾਂ ਹਿੱਸਿਆਂ ਦੇ ਨਾਲ-ਨਾਲ UI ਲੇਅਰ ਕੰਪੋਨੈਂਟਸ ਦੀ ਵੀ ਇੱਕ ਕਰਸਰੀ ਜਾਂਚ ਸੰਭਵ ਨਹੀਂ ਹੈ, ਇਸਲਈ ਇਸ ਭਾਗ ਦੇ ਬਾਕੀ ਭਾਗ ਵਿੱਚ ਅਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਮੁੱਖ "ਕੋਰ" ਭਾਗਾਂ ਦੀ ਸੰਖੇਪ ਜਾਣਕਾਰੀ ਤੱਕ ਸੀਮਤ ਰੱਖਾਂਗੇ। ਈਲੈਪਸ ਪਲੇਟਫਾਰਮ ਅਤੇ ਜੇ.ਡੀ.ਟੀ.

ਕੋਰ ਰਨਟਾਈਮ

Eclipse ਪਲੱਗਇਨ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਆਧਾਰਿਤ ਹੈ ਓਐਸਜੀ ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤਾ ਗਿਆ ਹੈ ਗ੍ਰਹਿਣ ਸਮਰੂਪ. ਹਰ ਇਕਲਿਪਸ ਪਲੱਗਇਨ ਇੱਕ OSGi ਬੰਡਲ ਹੈ। OSGi ਨਿਰਧਾਰਨ, ਖਾਸ ਤੌਰ 'ਤੇ, ਸੰਸਕਰਣ ਅਤੇ ਨਿਰਭਰਤਾ ਰੈਜ਼ੋਲੂਸ਼ਨ ਲਈ ਵਿਧੀਆਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਇਹਨਾਂ ਮਿਆਰੀ ਵਿਧੀਆਂ ਤੋਂ ਇਲਾਵਾ, ਇਕਵਿਨੋਕਸ ਸੰਕਲਪ ਨੂੰ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਵਿਸਥਾਰ ਬਿੰਦੂ. ਹਰੇਕ ਪਲੱਗਇਨ ਆਪਣੇ ਖੁਦ ਦੇ ਐਕਸਟੈਂਸ਼ਨ ਪੁਆਇੰਟਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਸੇ ਜਾਂ ਹੋਰ ਪਲੱਗਇਨਾਂ ਦੁਆਰਾ ਪਰਿਭਾਸ਼ਿਤ ਐਕਸਟੈਂਸ਼ਨ ਪੁਆਇੰਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਸਿਸਟਮ ਵਿੱਚ ਵਾਧੂ ਕਾਰਜਸ਼ੀਲਤਾ ("ਐਕਸਟੈਂਸ਼ਨ") ਵੀ ਪੇਸ਼ ਕਰ ਸਕਦਾ ਹੈ। OSGi ਅਤੇ ਇਕਵਿਨੋਕਸ ਵਿਧੀ ਦਾ ਕੋਈ ਵੀ ਵਿਸਤ੍ਰਿਤ ਵੇਰਵਾ ਇਸ ਲੇਖ ਦੇ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਹੈ। ਆਓ ਇਹ ਨੋਟ ਕਰੀਏ ਕਿ ਇਕਲਿਪਸ ਵਿੱਚ ਮਾਡਿਊਲਰਾਈਜ਼ੇਸ਼ਨ ਕੁੱਲ ਹੈ (ਕਿਸੇ ਵੀ ਸਬ-ਸਿਸਟਮ, ਜਿਸ ਵਿੱਚ ਰਨਟਾਈਮ ਵੀ ਸ਼ਾਮਲ ਹੈ, ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਪਲੱਗਇਨ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ), ਅਤੇ ਇੱਕਲਿਪਸ ਵਿੱਚ ਲਗਭਗ ਹਰ ਚੀਜ਼ ਇੱਕ ਐਕਸਟੈਂਸ਼ਨ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਸਿਧਾਂਤ OSGi ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਬਹੁਤ ਪਹਿਲਾਂ ਈਲੈਪਸ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਸਨ (ਉਸ ਸਮੇਂ ਉਹਨਾਂ ਨੇ ਆਪਣੀ ਤਕਨੀਕ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਸੀ, ਜੋ ਕਿ OSGi ਦੇ ਸਮਾਨ ਹੈ)।

ਕੋਰ ਵਰਕਸਪੇਸ

Eclipse ਪਲੇਟਫਾਰਮ ਦੇ ਸਿਖਰ 'ਤੇ ਬਣਿਆ ਲਗਭਗ ਕੋਈ ਵੀ ਏਕੀਕ੍ਰਿਤ ਵਿਕਾਸ ਵਾਤਾਵਰਣ Eclipse ਵਰਕਸਪੇਸ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ। ਇਹ ਉਹ ਵਰਕਸਪੇਸ ਹੈ ਜਿਸ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ IDE ਵਿੱਚ ਵਿਕਸਤ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਸਰੋਤ ਕੋਡ ਹੁੰਦਾ ਹੈ। ਵਰਕਸਪੇਸ ਸਿੱਧੇ ਫਾਈਲ ਸਿਸਟਮ ਨਾਲ ਨਕਸ਼ੇ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਫੋਲਡਰਾਂ ਅਤੇ ਫਾਈਲਾਂ ਵਾਲੇ ਪ੍ਰੋਜੈਕਟ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਇਹਨਾਂ ਪ੍ਰੋਜੈਕਟਾਂ, ਫੋਲਡਰਾਂ ਅਤੇ ਫਾਈਲਾਂ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਸਰੋਤ ਵਰਕਸਪੇਸ। Eclipse ਵਿੱਚ ਵਰਕਸਪੇਸ ਲਾਗੂ ਕਰਨਾ ਫਾਈਲ ਸਿਸਟਮ ਦੇ ਸਬੰਧ ਵਿੱਚ ਇੱਕ ਕੈਸ਼ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਸਰੋਤ ਟ੍ਰੀ ਦੇ ਟਰੈਵਰਸਲ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਕਰਨਾ ਸੰਭਵ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਵਰਕਸਪੇਸ ਕਈ ਵਾਧੂ ਸੇਵਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਸਮੇਤ ਸਰੋਤ ਤਬਦੀਲੀ ਲਈ ਸੂਚਨਾ ਵਿਧੀ и ਵਾਧੇ ਵਾਲਾ ਬਿਲਡਰ ਬੁਨਿਆਦੀ ਢਾਂਚਾ.

ਕੋਰ ਰਿਸੋਰਸਸ ਕੰਪੋਨੈਂਟ (org.eclipse.core.resources ਪਲੱਗਇਨ) ਵਰਕਸਪੇਸ ਅਤੇ ਇਸਦੇ ਸਰੋਤਾਂ ਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਖਾਸ ਤੌਰ 'ਤੇ, ਇਹ ਕੰਪੋਨੈਂਟ ਫਾਰਮ ਵਿੱਚ ਵਰਕਸਪੇਸ ਤੱਕ ਪ੍ਰੋਗਰਾਮੇਟਿਕ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਸਰੋਤ ਮਾਡਲ. ਇਸ ਮਾਡਲ ਦੇ ਨਾਲ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ, ਗਾਹਕਾਂ ਨੂੰ ਇੱਕ ਸਰੋਤ ਲਈ ਇੱਕ ਲਿੰਕ ਪੇਸ਼ ਕਰਨ ਲਈ ਇੱਕ ਸਧਾਰਨ ਤਰੀਕੇ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ. ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਆਬਜੈਕਟ ਨੂੰ ਲੁਕਾਉਣਾ ਫਾਇਦੇਮੰਦ ਹੋਵੇਗਾ ਜੋ ਕਲਾਇੰਟ ਐਕਸੈਸ ਤੋਂ ਮਾਡਲ ਵਿੱਚ ਸਰੋਤ ਦੀ ਸਥਿਤੀ ਨੂੰ ਸਿੱਧਾ ਸਟੋਰ ਕਰਦਾ ਹੈ। ਨਹੀਂ ਤਾਂ, ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਫਾਈਲ ਨੂੰ ਮਿਟਾਉਣ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਕਲਾਇੰਟ ਇੱਕ ਆਬਜੈਕਟ ਨੂੰ ਰੱਖਣਾ ਜਾਰੀ ਰੱਖ ਸਕਦਾ ਹੈ ਜੋ ਹੁਣ ਮਾਡਲ ਵਿੱਚ ਨਹੀਂ ਹੈ, ਆਉਣ ਵਾਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦੇ ਨਾਲ. Eclipse ਨਾਮ ਦੀ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ ਹੈਂਡਲ ਸਰੋਤ। ਹੈਂਡਲ ਇੱਕ ਕੁੰਜੀ ਦੇ ਤੌਰ ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ (ਇਹ ਸਿਰਫ ਵਰਕਸਪੇਸ ਵਿੱਚ ਸਰੋਤ ਦਾ ਮਾਰਗ ਜਾਣਦਾ ਹੈ) ਅਤੇ ਅੰਦਰੂਨੀ ਮਾਡਲ ਆਬਜੈਕਟ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ, ਜੋ ਸਰੋਤ ਦੀ ਸਥਿਤੀ ਬਾਰੇ ਜਾਣਕਾਰੀ ਨੂੰ ਸਿੱਧਾ ਸਟੋਰ ਕਰਦਾ ਹੈ। ਇਹ ਡਿਜ਼ਾਈਨ ਪੈਟਰਨ ਦੀ ਇੱਕ ਪਰਿਵਰਤਨ ਹੈ ਹੈਂਡਲ/ਸਰੀਰ.

ਚੌਲ. ਚਿੱਤਰ 2 ਹੈਂਡਲ/ਬਾਡੀ ਮੁਹਾਵਰੇ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਸਰੋਤ ਮਾਡਲ 'ਤੇ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ। IResource ਇੰਟਰਫੇਸ ਇੱਕ ਸਰੋਤ ਦੇ ਹੈਂਡਲ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਅਤੇ ਇੱਕ API ਹੈ, ਰਿਸੋਰਸ ਕਲਾਸ ਦੇ ਉਲਟ, ਜੋ ਇਸ ਇੰਟਰਫੇਸ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਅਤੇ ResourceInfo ਕਲਾਸ, ਜੋ ਬਾਡੀ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਜੋ API ਨਹੀਂ ਹਨ। ਅਸੀਂ ਇਸ ਗੱਲ 'ਤੇ ਜ਼ੋਰ ਦਿੰਦੇ ਹਾਂ ਕਿ ਹੈਂਡਲ ਸਿਰਫ ਵਰਕਸਪੇਸ ਰੂਟ ਦੇ ਸੰਬੰਧ ਵਿੱਚ ਸਰੋਤ ਦਾ ਮਾਰਗ ਜਾਣਦਾ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਸਰੋਤ ਜਾਣਕਾਰੀ ਦਾ ਲਿੰਕ ਨਹੀਂ ਹੈ। ਸਰੋਤ ਜਾਣਕਾਰੀ ਵਸਤੂਆਂ ਇੱਕ ਅਖੌਤੀ "ਐਲੀਮੈਂਟ ਟ੍ਰੀ" ਬਣਾਉਂਦੀਆਂ ਹਨ। ਇਹ ਡਾਟਾ ਢਾਂਚਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ ਮੈਮੋਰੀ ਵਿੱਚ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ. ਇੱਕ ਹੈਂਡਲ ਨਾਲ ਸੰਬੰਧਿਤ ਸਰੋਤ ਜਾਣਕਾਰੀ ਉਦਾਹਰਨ ਲੱਭਣ ਲਈ, ਤੱਤ ਦੇ ਰੁੱਖ ਨੂੰ ਉਸ ਹੈਂਡਲ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਮਾਰਗ ਦੇ ਅਨੁਸਾਰ ਲੰਘਾਇਆ ਜਾਂਦਾ ਹੈ।

ਚੌਲ. 2. IRResource ਅਤੇ ResourceInfo

ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਬਾਅਦ ਵਿੱਚ ਦੇਖਾਂਗੇ, ਸਰੋਤ ਮਾਡਲ (ਅਸੀਂ ਇਸਨੂੰ ਹੈਂਡਲ-ਅਧਾਰਿਤ ਕਹਿ ਸਕਦੇ ਹਾਂ) ਦਾ ਮੂਲ ਡਿਜ਼ਾਈਨ ਈਲੈਪਸ ਵਿੱਚ ਦੂਜੇ ਮਾਡਲਾਂ ਲਈ ਵੀ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਹੁਣ ਲਈ, ਆਓ ਇਸ ਡਿਜ਼ਾਈਨ ਦੀਆਂ ਕੁਝ ਵਿਸ਼ੇਸ਼ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਸੂਚੀਬੱਧ ਕਰੀਏ:

• ਹੈਂਡਲ ਇੱਕ ਮੁੱਲ ਵਸਤੂ ਹੈ। ਮੁੱਲ ਵਸਤੂਆਂ ਅਟੱਲ ਵਸਤੂਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਸਮਾਨਤਾ ਪਛਾਣ 'ਤੇ ਅਧਾਰਤ ਨਹੀਂ ਹੁੰਦੀ ਹੈ। ਅਜਿਹੀਆਂ ਵਸਤੂਆਂ ਨੂੰ ਹੈਸ਼ਡ ਕੰਟੇਨਰਾਂ ਵਿੱਚ ਇੱਕ ਕੁੰਜੀ ਵਜੋਂ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਹੈਂਡਲ ਦੀਆਂ ਕਈ ਉਦਾਹਰਨਾਂ ਇੱਕੋ ਸਰੋਤ ਦਾ ਹਵਾਲਾ ਦੇ ਸਕਦੀਆਂ ਹਨ। ਉਹਨਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਬਰਾਬਰ (ਆਬਜੈਕਟ) ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
• ਹੈਂਡਲ ਇੱਕ ਸਰੋਤ ਦੇ ਵਿਵਹਾਰ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਪਰ ਇਸ ਵਿੱਚ ਸਰੋਤ ਦੀ ਸਥਿਤੀ ਬਾਰੇ ਜਾਣਕਾਰੀ ਨਹੀਂ ਹੁੰਦੀ ਹੈ (ਸਿਰਫ਼ ਡੇਟਾ ਜੋ ਇਹ ਸਟੋਰ ਕਰਦਾ ਹੈ ਉਹ "ਕੁੰਜੀ", ਸਰੋਤ ਦਾ ਮਾਰਗ ਹੈ)।
• ਹੈਂਡਲ ਇੱਕ ਅਜਿਹੇ ਸਰੋਤ ਦਾ ਹਵਾਲਾ ਦੇ ਸਕਦਾ ਹੈ ਜੋ ਮੌਜੂਦ ਨਹੀਂ ਹੈ (ਜਾਂ ਤਾਂ ਇੱਕ ਸਰੋਤ ਜੋ ਅਜੇ ਤੱਕ ਨਹੀਂ ਬਣਾਇਆ ਗਿਆ ਹੈ, ਜਾਂ ਇੱਕ ਸਰੋਤ ਜੋ ਪਹਿਲਾਂ ਹੀ ਮਿਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ)। ਇੱਕ ਸਰੋਤ ਦੀ ਮੌਜੂਦਗੀ ਨੂੰ IResource.exists() ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਜਾਂਚਿਆ ਜਾ ਸਕਦਾ ਹੈ।
• ਕੁਝ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਸਿਰਫ਼ ਹੈਂਡਲ ਵਿੱਚ ਸਟੋਰ ਕੀਤੀ ਜਾਣਕਾਰੀ ਦੇ ਆਧਾਰ 'ਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (ਅਖੌਤੀ ਹੈਂਡਲ-ਓਨਲੀ ਓਪਰੇਸ਼ਨ)। ਉਦਾਹਰਨਾਂ ਹਨ IResource.getParent(), getFullPath(), ਆਦਿ। ਅਜਿਹੀ ਕਾਰਵਾਈ ਨੂੰ ਕਾਮਯਾਬ ਕਰਨ ਲਈ ਸਰੋਤ ਦੀ ਮੌਜੂਦਗੀ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਓਪਰੇਸ਼ਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਫਲ ਹੋਣ ਲਈ ਸਰੋਤ ਦੀ ਮੌਜੂਦਗੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜੇਕਰ ਸਰੋਤ ਮੌਜੂਦ ਨਹੀਂ ਹੈ ਤਾਂ ਇੱਕ CoreException ਸੁੱਟੋ।

ਈਲੈਪਸ ਵਰਕਸਪੇਸ ਸਰੋਤ ਤਬਦੀਲੀਆਂ ਨੂੰ ਸੂਚਿਤ ਕਰਨ ਲਈ ਇੱਕ ਕੁਸ਼ਲ ਵਿਧੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ (ਚਿੱਤਰ 3)। ਸਰੋਤ ਜਾਂ ਤਾਂ ਈਲੈਪਸ IDE ਦੇ ਅੰਦਰ ਕੀਤੀਆਂ ਕਾਰਵਾਈਆਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਜਾਂ ਫਾਈਲ ਸਿਸਟਮ ਨਾਲ ਸਮਕਾਲੀਕਰਨ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਬਦਲ ਸਕਦੇ ਹਨ। ਦੋਵਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਗਾਹਕ ਜੋ ਸੂਚਨਾਵਾਂ ਦੀ ਗਾਹਕੀ ਲੈਂਦੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ "ਸਰੋਤ ਡੈਲਟਾ" ਦੇ ਰੂਪ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਬਾਰੇ ਵਿਸਤ੍ਰਿਤ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਡੈਲਟਾ ਇੱਕ ਵਰਕਸਪੇਸ ਸਰੋਤ (ਉਪ-) ਰੁੱਖ ਦੀਆਂ ਦੋ ਅਵਸਥਾਵਾਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ ਅਤੇ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇੱਕ ਰੁੱਖ ਹੈ, ਜਿਸਦਾ ਹਰੇਕ ਨੋਡ ਇੱਕ ਸਰੋਤ ਵਿੱਚ ਤਬਦੀਲੀ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ ਅਤੇ ਅਗਲੇ ਪੱਧਰ 'ਤੇ ਡੈਲਟਾ ਦੀ ਸੂਚੀ ਰੱਖਦਾ ਹੈ ਜੋ ਬਾਲ ਸਰੋਤਾਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ।

ਚੌਲ. 3. IResourceChangeEvent ਅਤੇ IResourceDelta

ਸਰੋਤ ਡੈਲਟਾ 'ਤੇ ਆਧਾਰਿਤ ਸੂਚਨਾ ਵਿਧੀ ਦੀਆਂ ਹੇਠ ਲਿਖੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ:

• ਇੱਕੋ ਬਣਤਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਸਿੰਗਲ ਤਬਦੀਲੀ ਅਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਦਾ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ, ਕਿਉਂਕਿ ਡੈਲਟਾ ਨੂੰ ਆਵਰਤੀ ਰਚਨਾ ਦੇ ਸਿਧਾਂਤ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਸਬਸਕ੍ਰਾਈਬਰ ਕਲਾਇੰਟ ਡੈਲਟਾ ਦੇ ਇੱਕ ਟ੍ਰੀ ਦੁਆਰਾ ਰੀਕਰਸੀਵ ਡਿਸੇਂਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਰੋਤ ਪਰਿਵਰਤਨ ਸੂਚਨਾਵਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰ ਸਕਦੇ ਹਨ।
• ਡੈਲਟਾ ਵਿੱਚ ਸਰੋਤ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਬਾਰੇ ਪੂਰੀ ਜਾਣਕਾਰੀ ਹੁੰਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਇਸਦੀ ਗਤੀ ਅਤੇ/ਜਾਂ ਇਸ ਨਾਲ ਜੁੜੇ "ਮਾਰਕਰਾਂ" ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਸ਼ਾਮਲ ਹੁੰਦੀਆਂ ਹਨ (ਉਦਾਹਰਨ ਲਈ, ਸੰਕਲਨ ਦੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਮਾਰਕਰ ਵਜੋਂ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ)।
• ਕਿਉਂਕਿ ਸਰੋਤ ਹਵਾਲੇ ਹੈਂਡਲ ਦੁਆਰਾ ਬਣਾਏ ਜਾਂਦੇ ਹਨ, ਡੈਲਟਾ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਰਿਮੋਟ ਸਰੋਤ ਦਾ ਹਵਾਲਾ ਦੇ ਸਕਦਾ ਹੈ।

ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਜਲਦੀ ਹੀ ਦੇਖਾਂਗੇ, ਸਰੋਤ ਮਾਡਲ ਤਬਦੀਲੀ ਨੋਟੀਫਿਕੇਸ਼ਨ ਵਿਧੀ ਦੇ ਡਿਜ਼ਾਈਨ ਦੇ ਮੁੱਖ ਭਾਗ ਹੋਰ ਹੈਂਡਲ-ਅਧਾਰਿਤ ਮਾਡਲਾਂ ਲਈ ਵੀ ਢੁਕਵੇਂ ਹਨ।

ਜੇਡੀਟੀ ਕੋਰ

ਈਲੈਪਸ ਵਰਕਸਪੇਸ ਰਿਸੋਰਸ ਮਾਡਲ ਇੱਕ ਬੁਨਿਆਦੀ ਭਾਸ਼ਾ-ਅਗਿਆਨਵਾਦੀ ਮਾਡਲ ਹੈ। JDT ਕੋਰ ਕੰਪੋਨੈਂਟ (ਪਲੱਗਇਨ org.eclipse.jdt.core) ਇੱਕ ਜਾਵਾ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਵਰਕਸਪੇਸ ਢਾਂਚੇ ਨੂੰ ਨੈਵੀਗੇਟ ਕਰਨ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ ਇੱਕ API ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਅਖੌਤੀ "ਜਾਵਾ ਮਾਡਲ" (ਜਾਵਾ ਮਾਡਲ). ਇਸ API ਨੂੰ ਜਾਵਾ ਤੱਤਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਿਵੇਂ ਕਿ ਅੰਡਰਲਾਈੰਗ ਸਰੋਤ ਮਾਡਲ API ਦੇ ਉਲਟ, ਜੋ ਕਿ ਫੋਲਡਰਾਂ ਅਤੇ ਫਾਈਲਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਜਾਵਾ ਐਲੀਮੈਂਟ ਟ੍ਰੀ ਦੇ ਮੁੱਖ ਇੰਟਰਫੇਸ ਚਿੱਤਰ ਵਿੱਚ ਦਿਖਾਏ ਗਏ ਹਨ। 4.

ਚੌਲ. 4. ਜਾਵਾ ਮਾਡਲ ਐਲੀਮੈਂਟਸ

ਜਾਵਾ ਮਾਡਲ ਉਹੀ ਹੈਂਡਲ/ਬਾਡੀ ਮੁਹਾਵਰੇ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਸਰੋਤ ਮਾਡਲ (ਚਿੱਤਰ 5)। IJavaElement ਹੈਂਡਲ ਹੈ, ਅਤੇ JavaElementInfo ਬਾਡੀ ਦੀ ਭੂਮਿਕਾ ਨਿਭਾਉਂਦਾ ਹੈ। IJavaElement ਇੰਟਰਫੇਸ ਇੱਕ ਪ੍ਰੋਟੋਕੋਲ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜੋ ਸਾਰੇ ਜਾਵਾ ਤੱਤਾਂ ਲਈ ਸਾਂਝਾ ਹੁੰਦਾ ਹੈ। ਇਸ ਦੀਆਂ ਕੁਝ ਵਿਧੀਆਂ ਸਿਰਫ਼ ਹੈਂਡਲ ਹਨ: getElementName(), getParent(), ਆਦਿ। JavaElementInfo ਆਬਜੈਕਟ ਸੰਬੰਧਿਤ ਤੱਤ ਦੀ ਸਥਿਤੀ ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ: ਇਸਦੀ ਬਣਤਰ ਅਤੇ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ।

ਚੌਲ. 5. IJavaElement ਅਤੇ JavaElementInfo

ਜਾਵਾ ਮਾਡਲ ਵਿੱਚ ਸਰੋਤ ਮਾਡਲ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਬੁਨਿਆਦੀ ਹੈਂਡਲ/ਬਾਡੀ ਡਿਜ਼ਾਈਨ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਕੁਝ ਅੰਤਰ ਹਨ। ਜਿਵੇਂ ਕਿ ਉੱਪਰ ਨੋਟ ਕੀਤਾ ਗਿਆ ਹੈ, ਸਰੋਤ ਮਾਡਲ ਵਿੱਚ, ਐਲੀਮੈਂਟ ਟ੍ਰੀ, ਜਿਸ ਦੇ ਨੋਡ ਸਰੋਤ ਜਾਣਕਾਰੀ ਆਬਜੈਕਟ ਹਨ, ਪੂਰੀ ਤਰ੍ਹਾਂ ਮੈਮੋਰੀ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ। ਪਰ ਜਾਵਾ ਮਾਡਲ ਵਿੱਚ ਸਰੋਤ ਟ੍ਰੀ ਨਾਲੋਂ ਕਾਫ਼ੀ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਤੱਤ ਹੋ ਸਕਦੇ ਹਨ, ਕਿਉਂਕਿ ਇਹ .java ਅਤੇ .class ਫਾਈਲਾਂ ਦੇ ਅੰਦਰੂਨੀ ਢਾਂਚੇ ਨੂੰ ਵੀ ਦਰਸਾਉਂਦਾ ਹੈ: ਕਿਸਮਾਂ, ਖੇਤਰ ਅਤੇ ਢੰਗ।

ਮੈਮੋਰੀ ਵਿੱਚ ਐਲੀਮੈਂਟਸ ਦੇ ਪੂਰੇ ਟ੍ਰੀ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ ਬਣਾਉਣ ਤੋਂ ਬਚਣ ਲਈ, ਜਾਵਾ ਮਾਡਲ ਸਥਾਪਨ ਐਲੀਮੈਂਟ ਜਾਣਕਾਰੀ ਦੇ ਇੱਕ ਸੀਮਤ ਆਕਾਰ ਦੇ LRU ਕੈਸ਼ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਜਿੱਥੇ ਕੁੰਜੀ IJavaElement ਨੂੰ ਹੈਂਡਲ ਕਰਦੀ ਹੈ। ਤੱਤ ਜਾਣਕਾਰੀ ਆਬਜੈਕਟ ਮੰਗ 'ਤੇ ਬਣਾਏ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਐਲੀਮੈਂਟ ਟ੍ਰੀ ਨੈਵੀਗੇਟ ਹੁੰਦਾ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸਭ ਤੋਂ ਘੱਟ ਅਕਸਰ ਵਰਤੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਆਈਟਮਾਂ ਨੂੰ ਕੈਸ਼ ਵਿੱਚੋਂ ਕੱਢਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਮਾਡਲ ਦੀ ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਨਿਰਧਾਰਤ ਕੈਸ਼ ਆਕਾਰ ਤੱਕ ਸੀਮਿਤ ਰਹਿੰਦੀ ਹੈ। ਇਹ ਹੈਂਡਲ-ਅਧਾਰਿਤ ਡਿਜ਼ਾਈਨ ਦਾ ਇੱਕ ਹੋਰ ਫਾਇਦਾ ਹੈ, ਜੋ ਕਲਾਇੰਟ ਕੋਡ ਤੋਂ ਅਜਿਹੇ ਲਾਗੂਕਰਨ ਵੇਰਵਿਆਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਲੁਕਾਉਂਦਾ ਹੈ।

Java ਐਲੀਮੈਂਟਸ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਨੂੰ ਸੂਚਿਤ ਕਰਨ ਦੀ ਵਿਧੀ ਆਮ ਤੌਰ 'ਤੇ ਉੱਪਰ ਦੱਸੇ ਗਏ ਵਰਕਸਪੇਸ ਸਰੋਤਾਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਨੂੰ ਟਰੈਕ ਕਰਨ ਲਈ ਵਿਧੀ ਦੇ ਸਮਾਨ ਹੈ। ਜਾਵਾ ਮਾਡਲ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਦੀ ਇੱਛਾ ਰੱਖਣ ਵਾਲਾ ਇੱਕ ਕਲਾਇੰਟ ਸੂਚਨਾਵਾਂ ਦੀ ਗਾਹਕੀ ਲੈਂਦਾ ਹੈ, ਜੋ ਕਿ ਇੱਕ ElementChangedEvent ਵਸਤੂ ਦੇ ਰੂਪ ਵਿੱਚ ਪ੍ਰਸਤੁਤ ਹੁੰਦੇ ਹਨ ਜਿਸ ਵਿੱਚ ਇੱਕ IJavaElementDelta (ਚਿੱਤਰ 6) ਹੁੰਦਾ ਹੈ।

ਚੌਲ. 6. ElementChangedEvent ਅਤੇ IJavaElementDelta

ਜਾਵਾ ਮਾਡਲ ਵਿੱਚ ਵਿਧੀ ਬਾਡੀ ਜਾਂ ਨਾਮ ਰੈਜ਼ੋਲੂਸ਼ਨ ਬਾਰੇ ਜਾਣਕਾਰੀ ਨਹੀਂ ਹੈ, ਇਸਲਈ ਜਾਵਾ ਵਿੱਚ ਲਿਖੇ ਕੋਡ ਦੇ ਵਿਸਤ੍ਰਿਤ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ, JDT ਕੋਰ ਇੱਕ ਵਾਧੂ (ਗੈਰ-ਹੈਂਡਲ-ਅਧਾਰਿਤ) ਮਾਡਲ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ: ਐਬਸਟਰੈਕਟ ਸਿੰਟੈਕਸ ਟ੍ਰੀ (ਸਾਰ ਸੰਟੈਕਸ ਟ੍ਰੀ, AST)। AST ਸਰੋਤ ਟੈਕਸਟ ਨੂੰ ਪਾਰਸ ਕਰਨ ਦੇ ਨਤੀਜੇ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। AST ਨੋਡ ਸਰੋਤ ਮੋਡੀਊਲ (ਘੋਸ਼ਣਾ, ਆਪਰੇਟਰ, ਸਮੀਕਰਨ, ਆਦਿ) ਦੀ ਬਣਤਰ ਦੇ ਤੱਤਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ ਅਤੇ ਸਰੋਤ ਟੈਕਸਟ ਵਿੱਚ ਅਨੁਸਾਰੀ ਤੱਤ ਦੇ ਧੁਰੇ ਬਾਰੇ ਜਾਣਕਾਰੀ ਰੱਖਦੇ ਹਨ, ਨਾਲ ਹੀ (ਇੱਕ ਵਿਕਲਪ ਵਜੋਂ) ਵਿੱਚ ਨਾਮ ਰੈਜ਼ੋਲੂਸ਼ਨ ਬਾਰੇ ਜਾਣਕਾਰੀ ਅਖੌਤੀ ਲਿੰਕਾਂ ਦਾ ਰੂਪ ਬਾਈਡਿੰਗਜ਼. ਬਾਈਡਿੰਗ ਉਹ ਵਸਤੂਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਨਾਮਿਤ ਇਕਾਈਆਂ ਨੂੰ ਦਰਸਾਉਂਦੀਆਂ ਹਨ, ਜਿਵੇਂ ਕਿ ਕਿਸਮਾਂ, ਵਿਧੀਆਂ ਅਤੇ ਵੇਰੀਏਬਲ, ਜੋ ਕੰਪਾਈਲਰ ਨੂੰ ਜਾਣੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। AST ਨੋਡਾਂ ਦੇ ਉਲਟ, ਜੋ ਇੱਕ ਰੁੱਖ ਬਣਾਉਂਦੇ ਹਨ, ਬਾਈਡਿੰਗਸ ਕਰਾਸ-ਰੈਫਰੈਂਸਿੰਗ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਗ੍ਰਾਫ ਬਣਾਉਂਦੇ ਹਨ। ਐਬਸਟਰੈਕਟ ਕਲਾਸ ASTNode ਸਾਰੇ AST ਨੋਡਾਂ ਲਈ ਆਮ ਬੇਸ ਕਲਾਸ ਹੈ। ASTNode ਉਪ-ਸ਼੍ਰੇਣੀਆਂ ਜਾਵਾ ਭਾਸ਼ਾ ਦੇ ਖਾਸ ਸਿੰਟੈਕਟਿਕ ਨਿਰਮਾਣ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ।

ਕਿਉਂਕਿ ਸਿੰਟੈਕਸ ਟ੍ਰੀ ਬਹੁਤ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਮੈਮੋਰੀ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਨ, ਜੇਡੀਟੀ ਕਿਰਿਆਸ਼ੀਲ ਸੰਪਾਦਕ ਲਈ ਕੇਵਲ ਇੱਕ AST ਕੈਸ਼ ਕਰਦਾ ਹੈ। ਜਾਵਾ ਮਾਡਲ ਦੇ ਉਲਟ, AST ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ "ਇੰਟਰਮੀਡੀਏਟ," "ਅਸਥਾਈ" ਮਾਡਲ ਵਜੋਂ ਦੇਖਿਆ ਜਾਂਦਾ ਹੈ ਜਿਸ ਦੇ ਮੈਂਬਰਾਂ ਨੂੰ ਓਪਰੇਸ਼ਨ ਦੇ ਸੰਦਰਭ ਤੋਂ ਬਾਹਰ ਗਾਹਕਾਂ ਦੁਆਰਾ ਹਵਾਲਾ ਨਹੀਂ ਦਿੱਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਨਾਲ AST ਦੀ ਸਿਰਜਣਾ ਹੋਈ।

ਸੂਚੀਬੱਧ ਤਿੰਨ ਮਾਡਲ (ਜਾਵਾ ਮਾਡਲ, AST, ਬਾਈਡਿੰਗਜ਼) ਮਿਲ ਕੇ JDT ਵਿੱਚ "ਇੰਟੈਲੀਜੈਂਟ ਡਿਵੈਲਪਮੈਂਟ ਟੂਲ" ਬਣਾਉਣ ਲਈ ਆਧਾਰ ਬਣਾਉਂਦੇ ਹਨ, ਜਿਸ ਵਿੱਚ ਵੱਖ-ਵੱਖ "ਸਹਾਇਕਾਂ" ਦੇ ਨਾਲ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਜਾਵਾ ਸੰਪਾਦਕ, ਸਰੋਤ ਕੋਡ ਦੀ ਪ੍ਰਕਿਰਿਆ ਲਈ ਵੱਖ-ਵੱਖ ਕਾਰਵਾਈਆਂ (ਆਯਾਤ ਦੀ ਸੂਚੀ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਸਮੇਤ) ਸ਼ਾਮਲ ਹਨ। ਕਸਟਮਾਈਜ਼ਡ ਸ਼ੈਲੀ ਦੇ ਅਨੁਸਾਰ ਨਾਮ ਅਤੇ ਫਾਰਮੈਟਿੰਗ), ਖੋਜ ਅਤੇ ਰੀਫੈਕਟਰਿੰਗ ਟੂਲ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਜਾਵਾ ਮਾਡਲ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਭੂਮਿਕਾ ਨਿਭਾਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਉਹ ਹੈ ਜੋ ਵਿਕਸਤ ਕੀਤੇ ਜਾ ਰਹੇ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਬਣਤਰ ਦੀ ਵਿਜ਼ੂਅਲ ਨੁਮਾਇੰਦਗੀ ਲਈ ਅਧਾਰ ਵਜੋਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਪੈਕੇਜ ਐਕਸਪਲੋਰਰ, ਰੂਪਰੇਖਾ, ਖੋਜ, ਕਾਲ ਲੜੀ, ਅਤੇ ਦਰਜਾਬੰਦੀ ਦੀ ਕਿਸਮ)।

Eclipse ਕੰਪੋਨੈਂਟਸ 1C ਵਿੱਚ ਵਰਤੇ ਜਾਂਦੇ ਹਨ: ਐਂਟਰਪ੍ਰਾਈਜ਼ ਡਿਵੈਲਪਮੈਂਟ ਟੂਲਸ

ਚਿੱਤਰ ਵਿੱਚ. ਚਿੱਤਰ 7 ਈਲੈਪਸ ਕੰਪੋਨੈਂਟਸ ਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ ਜੋ 1C: ਐਂਟਰਪ੍ਰਾਈਜ਼ ਡਿਵੈਲਪਮੈਂਟ ਟੂਲਸ ਲਈ ਤਕਨਾਲੋਜੀ ਪਲੇਟਫਾਰਮ ਦੀ ਨੀਂਹ ਬਣਾਉਂਦੇ ਹਨ।

ਚੌਲ. 7. 1C: ਐਂਟਰਪ੍ਰਾਈਜ਼ ਡਿਵੈਲਪਮੈਂਟ ਟੂਲਸ ਲਈ ਇੱਕ ਪਲੇਟਫਾਰਮ ਵਜੋਂ ਗ੍ਰਹਿਣ

ਗ੍ਰਹਿਣ ਪਲੇਟਫਾਰਮ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਪਿਛਲੇ ਭਾਗ ਵਿੱਚ ਇਸ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਕੁਝ ਪਹਿਲੂਆਂ ਨੂੰ ਦੇਖਿਆ ਸੀ।

ਈਲੈਪਸ ਮਾਡਲਿੰਗ ਫਰੇਮਵਰਕ (ਈਐਮਐਫ) ਢਾਂਚਾਗਤ ਡੇਟਾ ਮਾਡਲਿੰਗ ਦੇ ਇੱਕ ਆਮ ਸਾਧਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। EMF Eclipse ਪਲੇਟਫਾਰਮ ਨਾਲ ਏਕੀਕ੍ਰਿਤ ਹੈ, ਪਰ ਨਿਯਮਤ Java ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਵੀ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਅਕਸਰ, ਨਵੇਂ ਈਲੈਪਸ ਡਿਵੈਲਪਰ ਪਹਿਲਾਂ ਹੀ ਈਐਮਐਫ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਣੂ ਹੁੰਦੇ ਹਨ, ਹਾਲਾਂਕਿ ਉਹ ਅਜੇ ਤੱਕ ਈਲੈਪਸ ਪਲੇਟਫਾਰਮ ਦੀਆਂ ਪੇਚੀਦਗੀਆਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਸਮਝਦੇ ਹਨ। ਅਜਿਹੀ ਚੰਗੀ-ਲਾਇਕ ਪ੍ਰਸਿੱਧੀ ਦੇ ਕਾਰਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਯੂਨੀਵਰਸਲ ਡਿਜ਼ਾਇਨ ਹੈ, ਜਿਸ ਵਿੱਚ ਹੋਰ ਚੀਜ਼ਾਂ ਦੇ ਨਾਲ, ਇੱਕ ਯੂਨੀਫਾਈਡ ਮੈਟਾ-ਪੱਧਰ API ਸ਼ਾਮਲ ਹੈ, ਜੋ ਤੁਹਾਨੂੰ ਕਿਸੇ ਵੀ EMF ਮਾਡਲ ਨਾਲ ਇੱਕ ਆਮ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। EMF ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਮਾਡਲ ਆਬਜੈਕਟ ਲਈ ਬੁਨਿਆਦੀ ਸਥਾਪਨ ਅਤੇ ਮੈਟਾ-ਮਾਡਲ 'ਤੇ ਆਧਾਰਿਤ ਮਾਡਲ ਕੋਡ ਬਣਾਉਣ ਲਈ ਸਬ-ਸਿਸਟਮ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਵਿਕਾਸ ਦੀ ਗਤੀ ਨੂੰ ਵਧਾਉਂਦੇ ਹਨ ਅਤੇ ਗਲਤੀਆਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ। EMF ਵਿੱਚ ਮਾਡਲਾਂ ਨੂੰ ਲੜੀਬੱਧ ਕਰਨ, ਮਾਡਲ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਨੂੰ ਟਰੈਕ ਕਰਨ ਅਤੇ ਹੋਰ ਬਹੁਤ ਕੁਝ ਕਰਨ ਲਈ ਵਿਧੀ ਵੀ ਸ਼ਾਮਲ ਹੈ।

ਕਿਸੇ ਵੀ ਸੱਚਮੁੱਚ ਆਮ-ਉਦੇਸ਼ ਵਾਲੇ ਟੂਲ ਵਾਂਗ, EMF ਮਾਡਲਿੰਗ ਸਮੱਸਿਆਵਾਂ ਦੀ ਇੱਕ ਵਿਸ਼ਾਲ ਸ਼੍ਰੇਣੀ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਢੁਕਵਾਂ ਹੈ, ਪਰ ਮਾਡਲਾਂ ਦੀਆਂ ਕੁਝ ਸ਼੍ਰੇਣੀਆਂ (ਉਦਾਹਰਣ ਵਜੋਂ, ਉੱਪਰ ਦੱਸੇ ਗਏ ਹੈਂਡਲ-ਅਧਾਰਿਤ ਮਾਡਲਾਂ) ਲਈ ਵਧੇਰੇ ਵਿਸ਼ੇਸ਼ ਮਾਡਲਿੰਗ ਸਾਧਨਾਂ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। EMF ਬਾਰੇ ਗੱਲ ਕਰਨਾ ਇੱਕ ਅਧੂਰਾ ਕੰਮ ਹੈ, ਖਾਸ ਤੌਰ 'ਤੇ ਇੱਕ ਲੇਖ ਦੀ ਸੀਮਤ ਸੀਮਾ ਦੇ ਅੰਦਰ, ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਵੱਖਰੀ ਕਿਤਾਬ ਦਾ ਵਿਸ਼ਾ ਹੈ, ਅਤੇ ਇੱਕ ਮੋਟੀ ਕਿਤਾਬ ਦਾ ਵਿਸ਼ਾ ਹੈ। ਆਓ ਇਹ ਨੋਟ ਕਰੀਏ ਕਿ ਈਐਮਐਫ ਦੇ ਅਧੀਨ ਸਧਾਰਣਕਰਣ ਦੀ ਉੱਚ-ਗੁਣਵੱਤਾ ਪ੍ਰਣਾਲੀ ਨੇ ਮਾਡਲਿੰਗ ਨੂੰ ਸਮਰਪਿਤ ਪ੍ਰੋਜੈਕਟਾਂ ਦੀ ਇੱਕ ਪੂਰੀ ਸ਼੍ਰੇਣੀ ਦੇ ਜਨਮ ਦੀ ਆਗਿਆ ਦਿੱਤੀ, ਜੋ ਕਿ ਉੱਚ-ਪੱਧਰੀ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ। ਈਲੈਪਸ ਮਾਡਲਿੰਗ EMF ਦੇ ਨਾਲ ਹੀ। ਅਜਿਹਾ ਹੀ ਇੱਕ ਪ੍ਰੋਜੈਕਟ Eclipse Xtext ਹੈ।

Eclipse Xtext ਇੱਕ "ਟੈਕਸਟ ਮਾਡਲਿੰਗ" ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। Xtext ਵਰਤਦਾ ਹੈ ਏਐਨਟੀਐਲਆਰ ਨਤੀਜੇ ਵਜੋਂ ASG (ਐਬਸਟਰੈਕਟ ਸਿਮੈਨਟਿਕ ਗ੍ਰਾਫ, ਜੋ ਕਿ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ AST ਅਤੇ ਬਾਈਡਿੰਗਾਂ ਦਾ ਸੁਮੇਲ ਹੈ) ਨੂੰ ਦਰਸਾਉਣ ਲਈ ਸਰੋਤ ਟੈਕਸਟ ਅਤੇ EMF ਨੂੰ ਪਾਰਸ ਕਰਨ ਲਈ, ਜਿਸ ਨੂੰ "ਸਿਮੈਂਟਿਕ ਮਾਡਲ" ਵੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। Xtext ਦੁਆਰਾ ਮਾਡਲ ਕੀਤੀ ਗਈ ਭਾਸ਼ਾ ਦਾ ਵਿਆਕਰਣ Xtext ਦੀ ਆਪਣੀ ਭਾਸ਼ਾ ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਨਾ ਸਿਰਫ਼ ANTLR ਲਈ ਇੱਕ ਵਿਆਕਰਣ ਵਰਣਨ ਤਿਆਰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਸਗੋਂ ਇੱਕ AST ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਵਿਧੀ (ਜਿਵੇਂ ਕਿ Xtext ਇੱਕ ਪਾਰਸਰ ਅਤੇ ਇੱਕ ਅਨਪਾਸਰਰ ਦੋਵੇਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ), ਇੱਕ ਸੰਦਰਭ ਸੰਕੇਤ, ਅਤੇ ਕਈ ਹੋਰ ਭਾਸ਼ਾ ਦੇ ਭਾਗਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਵੀ ਸਹਾਇਕ ਹੈ। ਦੂਜੇ ਪਾਸੇ, Xtext ਵਿੱਚ ਵਰਤੀ ਗਈ ਵਿਆਕਰਣ ਭਾਸ਼ਾ ANTLR ਵਿੱਚ ਵਰਤੀ ਗਈ ਵਿਆਕਰਣ ਭਾਸ਼ਾ ਨਾਲੋਂ ਘੱਟ ਲਚਕਦਾਰ ਹੈ। ਇਸ ਲਈ, ਕਈ ਵਾਰ ਲਾਗੂ ਕੀਤੀ ਭਾਸ਼ਾ ਨੂੰ ਐਕਸਟੈਕਸਟ ਨਾਲ "ਮੋੜਣਾ" ਜ਼ਰੂਰੀ ਹੁੰਦਾ ਹੈ, ਜੋ ਕਿ ਆਮ ਤੌਰ 'ਤੇ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੁੰਦੀ ਹੈ ਜੇਕਰ ਅਸੀਂ ਸਕ੍ਰੈਚ ਤੋਂ ਵਿਕਸਤ ਕੀਤੀ ਜਾ ਰਹੀ ਭਾਸ਼ਾ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਪਰ ਪਹਿਲਾਂ ਤੋਂ ਸਥਾਪਿਤ ਸੰਟੈਕਸ ਵਾਲੀਆਂ ਭਾਸ਼ਾਵਾਂ ਲਈ ਅਸਵੀਕਾਰਨਯੋਗ ਹੋ ਸਕਦਾ ਹੈ। ਇਸਦੇ ਬਾਵਜੂਦ, Xtext ਵਰਤਮਾਨ ਵਿੱਚ ਉਹਨਾਂ ਲਈ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਅਤੇ ਵਿਕਾਸ ਸਾਧਨਾਂ ਨੂੰ ਬਣਾਉਣ ਲਈ Eclipse ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਧ ਪਰਿਪੱਕ, ਵਿਸ਼ੇਸ਼ਤਾ-ਅਮੀਰ ਅਤੇ ਬਹੁਮੁਖੀ ਟੂਲ ਹੈ। ਖਾਸ ਤੌਰ 'ਤੇ, ਇਹ ਤੇਜ਼ ਪ੍ਰੋਟੋਟਾਈਪਿੰਗ ਲਈ ਇੱਕ ਆਦਰਸ਼ ਸਾਧਨ ਹੈ ਡੋਮੇਨ-ਵਿਸ਼ੇਸ਼ ਭਾਸ਼ਾਵਾਂ (ਡੋਮੇਨ-ਵਿਸ਼ੇਸ਼ ਭਾਸ਼ਾ, DSL)। ANTLR ਅਤੇ EMF 'ਤੇ ਅਧਾਰਤ ਉਪਰੋਕਤ "ਭਾਸ਼ਾ ਕੋਰ" ਤੋਂ ਇਲਾਵਾ, Xtext ਬਹੁਤ ਸਾਰੇ ਉਪਯੋਗੀ ਉੱਚ-ਪੱਧਰ ਦੇ ਹਿੱਸੇ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਇੰਡੈਕਸਿੰਗ ਵਿਧੀ, ਵਾਧਾ ਨਿਰਮਾਣ, ਇੱਕ "ਸਮਾਰਟ ਸੰਪਾਦਕ", ਅਤੇ ਹੋਰ ਬਹੁਤ ਕੁਝ ਸ਼ਾਮਲ ਹੈ, ਪਰ ਹੈਂਡਲ ਛੱਡਦਾ ਹੈ- ਆਧਾਰਿਤ ਭਾਸ਼ਾ ਮਾਡਲ. EMF ਵਾਂਗ, Xtext ਇੱਕ ਵੱਖਰੀ ਕਿਤਾਬ ਦੇ ਯੋਗ ਵਿਸ਼ਾ ਹੈ, ਅਤੇ ਅਸੀਂ ਇਸ ਸਮੇਂ ਇਸਦੀਆਂ ਸਾਰੀਆਂ ਸਮਰੱਥਾਵਾਂ ਬਾਰੇ ਸੰਖੇਪ ਵਿੱਚ ਗੱਲ ਕਰ ਸਕਦੇ ਹਾਂ।

1C: ਐਂਟਰਪ੍ਰਾਈਜ਼ ਡਿਵੈਲਪਮੈਂਟ ਟੂਲ ਸਰਗਰਮੀ ਨਾਲ ਈਐਮਐਫ ਆਪਣੇ ਆਪ ਅਤੇ ਕਈ ਹੋਰ ਇਕਲਿਪਸ ਮਾਡਲਿੰਗ ਪ੍ਰੋਜੈਕਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਖਾਸ ਤੌਰ 'ਤੇ, Xtext ਅਜਿਹੇ 1C:Enterprise ਭਾਸ਼ਾਵਾਂ ਜਿਵੇਂ ਕਿ ਬਿਲਟ-ਇਨ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ ਅਤੇ ਪੁੱਛਗਿੱਛ ਭਾਸ਼ਾ ਲਈ ਵਿਕਾਸ ਸਾਧਨਾਂ ਦੀ ਬੁਨਿਆਦ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਇਹਨਾਂ ਡਿਵੈਲਪਮੈਂਟ ਟੂਲਸ ਲਈ ਇੱਕ ਹੋਰ ਆਧਾਰ ਹੈ Eclipse Handly ਪ੍ਰੋਜੈਕਟ, ਜਿਸ ਬਾਰੇ ਅਸੀਂ ਹੋਰ ਵਿਸਥਾਰ ਵਿੱਚ ਚਰਚਾ ਕਰਾਂਗੇ (ਸੂਚੀਬੱਧ Eclipse ਭਾਗਾਂ ਵਿੱਚੋਂ, ਇਹ ਅਜੇ ਵੀ ਸਭ ਤੋਂ ਘੱਟ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ)।

ਹੱਥੀਂ ਗ੍ਰਹਿਣ ਕਰੋ, ਈਲੈਪਸ ਟੈਕਨਾਲੋਜੀ ਦੇ ਉੱਚ-ਪੱਧਰੀ ਪ੍ਰੋਜੈਕਟ ਦਾ ਇੱਕ ਉਪ-ਪ੍ਰੋਜੈਕਟ, 1 ਵਿੱਚ 2014C ਦੁਆਰਾ ਕੀਤੇ ਗਏ Eclipse ਫਾਊਂਡੇਸ਼ਨ ਵਿੱਚ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਕੋਡ ਯੋਗਦਾਨ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਉਭਰਿਆ। ਉਦੋਂ ਤੋਂ, 1C ਨੇ ਪ੍ਰੋਜੈਕਟ ਦੇ ਵਿਕਾਸ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਜਾਰੀ ਰੱਖਿਆ ਹੈ: ਹੈਂਡਲੀ ਕਮਿਟਰ ਕੰਪਨੀ ਦੇ ਕਰਮਚਾਰੀ ਹਨ। ਪ੍ਰੋਜੈਕਟ ਛੋਟਾ ਹੈ, ਪਰ ਇਹ ਇਕਲਿਪਸ ਵਿੱਚ ਇੱਕ ਵਿਲੱਖਣ ਸਥਾਨ ਰੱਖਦਾ ਹੈ: ਇਸਦਾ ਮੁੱਖ ਟੀਚਾ ਹੈਂਡਲ-ਅਧਾਰਿਤ ਮਾਡਲਾਂ ਦੇ ਵਿਕਾਸ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਹੈ।

ਹੈਂਡਲ-ਅਧਾਰਿਤ ਮਾਡਲਾਂ ਦੇ ਮੂਲ ਆਰਕੀਟੈਕਚਰਲ ਸਿਧਾਂਤ, ਜਿਵੇਂ ਕਿ ਹੈਂਡਲ/ਬਾਡੀ ਮੁਹਾਵਰੇ, ਨੂੰ ਉਦਾਹਰਣ ਵਜੋਂ ਸਰੋਤ ਮਾਡਲ ਅਤੇ ਜਾਵਾ ਮਾਡਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਉੱਪਰ ਚਰਚਾ ਕੀਤੀ ਗਈ ਸੀ। ਇਸ ਨੇ ਇਹ ਵੀ ਨੋਟ ਕੀਤਾ ਕਿ ਸਰੋਤ ਮਾਡਲ ਅਤੇ ਜਾਵਾ ਮਾਡਲ ਦੋਵੇਂ ਈਲੈਪਸ ਜਾਵਾ ਡਿਵੈਲਪਮੈਂਟ ਟੂਲਸ (JDT) ਲਈ ਮਹੱਤਵਪੂਰਨ ਬੁਨਿਆਦ ਹਨ। ਅਤੇ ਕਿਉਂਕਿ ਲਗਭਗ ਸਾਰੇ *DT Eclipse ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ JDT ਵਰਗਾ ਇੱਕ ਆਰਕੀਟੈਕਚਰ ਹੈ, ਇਹ ਕਹਿਣਾ ਕੋਈ ਅਤਿਕਥਨੀ ਨਹੀਂ ਹੋਵੇਗੀ ਕਿ ਹੈਂਡਲ-ਅਧਾਰਿਤ ਮਾਡਲਾਂ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਹਨ, ਜੇ ਸਾਰੇ ਈਲੈਪਸ ਪਲੇਟਫਾਰਮ ਦੇ ਸਿਖਰ 'ਤੇ ਬਣਾਏ ਗਏ IDE ਨਹੀਂ ਹਨ। ਉਦਾਹਰਨ ਲਈ, Eclipse C/C++ ਡਿਵੈਲਪਮੈਂਟ ਟੂਲਿੰਗ (CDT) ਵਿੱਚ ਇੱਕ ਹੈਂਡਲ-ਅਧਾਰਿਤ C/C++ ਮਾਡਲ ਹੈ ਜੋ CDT ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਉਹੀ ਭੂਮਿਕਾ ਨਿਭਾਉਂਦਾ ਹੈ ਜਿਵੇਂ ਜਾਵਾ ਮਾਡਲ JDT ਵਿੱਚ ਕਰਦਾ ਹੈ।

Handly ਤੋਂ ਪਹਿਲਾਂ, Eclipse ਨੇ ਹੈਂਡਲ-ਅਧਾਰਿਤ ਭਾਸ਼ਾ ਮਾਡਲ ਬਣਾਉਣ ਲਈ ਵਿਸ਼ੇਸ਼ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਨਹੀਂ ਕੀਤੀ ਸੀ। ਮਾਡਲ ਜੋ ਵਰਤਮਾਨ ਵਿੱਚ ਮੌਜੂਦ ਹਨ, ਮੁੱਖ ਤੌਰ 'ਤੇ ਜਾਵਾ ਮਾਡਲ ਕੋਡ (ਉਰਫ਼ ਕਾਪੀ/ਪੇਸਟ) ਨੂੰ ਸਿੱਧੇ ਰੂਪ ਵਿੱਚ ਅਨੁਕੂਲਿਤ ਕਰਕੇ ਬਣਾਏ ਗਏ ਸਨ। ਉਹਨਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ ਜਿੱਥੇ ਇਹ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਈਲੈਪਸ ਪਬਲਿਕ ਲਾਇਸੈਂਸ (ਈਪੀਐਲ)। (ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਇਹ ਆਮ ਤੌਰ 'ਤੇ, ਇਕਲਿਪਸ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ, ਆਪਣੇ ਆਪ ਲਈ ਕੋਈ ਕਾਨੂੰਨੀ ਮੁੱਦਾ ਨਹੀਂ ਹੈ, ਪਰ ਬੰਦ ਸਰੋਤ ਉਤਪਾਦਾਂ ਲਈ ਨਹੀਂ ਹੈ।) ਇਸਦੇ ਅੰਦਰੂਨੀ ਅੜਚਣ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਤਕਨੀਕ ਜਾਣੀਆਂ-ਪਛਾਣੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਪੇਸ਼ ਕਰਦੀ ਹੈ: ਗਲਤੀਆਂ ਦੇ ਅਨੁਕੂਲ ਹੋਣ 'ਤੇ ਕੋਡ ਡੁਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ, ਆਦਿ ਸਭ ਤੋਂ ਮਾੜੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਨਤੀਜੇ ਵਾਲੇ ਮਾਡਲ "ਆਪਣੇ ਆਪ ਵਿੱਚ ਚੀਜ਼ਾਂ" ਬਣੇ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਏਕੀਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਦਾ ਲਾਭ ਨਹੀਂ ਲੈਂਦੇ ਹਨ। ਪਰ ਹੈਂਡਲ-ਅਧਾਰਿਤ ਭਾਸ਼ਾ ਮਾਡਲਾਂ ਲਈ ਆਮ ਧਾਰਨਾਵਾਂ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲਾਂ ਨੂੰ ਅਲੱਗ ਕਰਨ ਨਾਲ ਉਹਨਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਮੁੜ ਵਰਤੋਂ ਯੋਗ ਭਾਗਾਂ ਦੀ ਸਿਰਜਣਾ ਹੋ ਸਕਦੀ ਹੈ, ਜਿਵੇਂ ਕਿ EMF ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਹੋਇਆ ਸੀ।

ਅਜਿਹਾ ਨਹੀਂ ਹੈ ਕਿ ਈਲੈਪਸ ਨੇ ਇਹਨਾਂ ਮੁੱਦਿਆਂ ਨੂੰ ਨਹੀਂ ਸਮਝਿਆ। 2005 ਵਿੱਚ ਵਾਪਸ ਮਾਰਟਿਨ ਐਸਚਲਿਮਨ, CDT ਪ੍ਰੋਟੋਟਾਈਪ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਦੇ ਤਜ਼ਰਬੇ ਦਾ ਸਾਰ ਦੇਣਾ, ਦਲੀਲ ਦਿੱਤੀ ਹੈਂਡਲ-ਅਧਾਰਿਤ ਮਾਡਲਾਂ ਸਮੇਤ ਭਾਸ਼ਾ ਮਾਡਲਾਂ ਲਈ ਇੱਕ ਸਾਂਝਾ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਬਣਾਉਣ ਦੀ ਲੋੜ। ਪਰ, ਜਿਵੇਂ ਕਿ ਅਕਸਰ ਹੁੰਦਾ ਹੈ, ਉੱਚ ਤਰਜੀਹ ਵਾਲੇ ਕੰਮਾਂ ਦੇ ਕਾਰਨ, ਇਹਨਾਂ ਵਿਚਾਰਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਕਦੇ ਵੀ ਇਸ ਦੇ ਨੇੜੇ ਨਹੀਂ ਆਇਆ। ਇਸ ਦੌਰਾਨ, *DT ਕੋਡ ਦਾ ਫੈਕਟਰਾਈਜ਼ੇਸ਼ਨ ਅਜੇ ਵੀ ਇਕਲਿਪਸ ਵਿੱਚ ਘੱਟ ਵਿਕਸਤ ਵਿਸ਼ਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ।

ਇੱਕ ਖਾਸ ਅਰਥਾਂ ਵਿੱਚ, ਹੈਂਡਲੀ ਪ੍ਰੋਜੈਕਟ EMF ਦੇ ਰੂਪ ਵਿੱਚ ਲਗਭਗ ਇੱਕੋ ਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਪਰ ਹੈਂਡਲ-ਅਧਾਰਿਤ ਮਾਡਲਾਂ ਲਈ, ਅਤੇ ਮੁੱਖ ਤੌਰ 'ਤੇ ਭਾਸ਼ਾਵਾਂ (ਜਿਵੇਂ, ਕੁਝ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ ਦੇ ਢਾਂਚੇ ਦੇ ਤੱਤਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ)। ਹੈਂਡਲੀ ਡਿਜ਼ਾਈਨ ਕਰਨ ਵੇਲੇ ਮੁੱਖ ਟੀਚੇ ਨਿਰਧਾਰਤ ਕੀਤੇ ਗਏ ਹਨ:

• ਵਿਸ਼ੇ ਖੇਤਰ ਦੇ ਮੁੱਖ ਐਬਸਟਰੈਕਸ਼ਨਾਂ ਦੀ ਪਛਾਣ।
• ਕੋਡ ਦੀ ਮੁੜ ਵਰਤੋਂ ਰਾਹੀਂ ਹੈਂਡਲ-ਅਧਾਰਿਤ ਭਾਸ਼ਾ ਮਾਡਲਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਗੁਣਵੱਤਾ ਵਿੱਚ ਸੁਧਾਰ ਅਤੇ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਘਟਾਉਣਾ।
• ਨਤੀਜੇ ਵਾਲੇ ਮਾਡਲਾਂ ਨੂੰ ਇੱਕ ਯੂਨੀਫਾਈਡ ਮੈਟਾ-ਪੱਧਰ API ਪ੍ਰਦਾਨ ਕਰਨਾ, ਆਮ IDE ਭਾਗ ਬਣਾਉਣਾ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਭਾਸ਼ਾ ਹੈਂਡਲ-ਅਧਾਰਿਤ ਮਾਡਲਾਂ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ।
• ਲਚਕਤਾ ਅਤੇ ਮਾਪਯੋਗਤਾ.
• Xtext ਨਾਲ ਏਕੀਕਰਣ (ਇੱਕ ਵੱਖਰੀ ਪਰਤ ਵਿੱਚ)

ਆਮ ਧਾਰਨਾਵਾਂ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲਾਂ ਨੂੰ ਉਜਾਗਰ ਕਰਨ ਲਈ, ਭਾਸ਼ਾ ਹੈਂਡਲ-ਅਧਾਰਿਤ ਮਾਡਲਾਂ ਦੇ ਮੌਜੂਦਾ ਲਾਗੂਕਰਨ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ ਗਿਆ ਸੀ। ਹੈਂਡਲੀ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਮੁੱਖ ਇੰਟਰਫੇਸ ਅਤੇ ਬੁਨਿਆਦੀ ਲਾਗੂਕਰਨ ਚਿੱਤਰ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਹੈ। 8.

ਚੌਲ. 8. ਹੈਂਡਲੀ ਐਲੀਮੈਂਟਸ ਦੇ ਆਮ ਇੰਟਰਫੇਸ ਅਤੇ ਬੁਨਿਆਦੀ ਲਾਗੂਕਰਨ

IElement ਇੰਟਰਫੇਸ ਇੱਕ ਤੱਤ ਦੇ ਹੈਂਡਲ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਅਤੇ ਸਾਰੇ ਹੈਂਡਲੀ-ਅਧਾਰਿਤ ਮਾਡਲਾਂ ਦੇ ਤੱਤਾਂ ਲਈ ਆਮ ਹੈ। ਐਬਸਟਰੈਕਟ ਕਲਾਸ ਐਲੀਮੈਂਟ ਜਨਰਲਾਈਜ਼ਡ ਹੈਂਡਲ/ਬਾਡੀ ਮਕੈਨਿਜ਼ਮ (ਚਿੱਤਰ 9) ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ।

ਚੌਲ. 9. ਆਈ ਐਲੀਮੈਂਟ ਅਤੇ ਆਮ ਹੈਂਡਲ/ਬਾਡੀ ਲਾਗੂ ਕਰਨਾ

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਹੈਂਡਲੀ ਮਾਡਲ ਐਲੀਮੈਂਟਸ (ਚਿੱਤਰ 10) ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਬਾਰੇ ਸੂਚਿਤ ਕਰਨ ਲਈ ਇੱਕ ਆਮ ਵਿਧੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਇਹ ਸਰੋਤ ਮਾਡਲ ਅਤੇ ਜਾਵਾ ਮਾਡਲ ਵਿੱਚ ਲਾਗੂ ਕੀਤੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਮਕੈਨਿਜ਼ਮ ਦੇ ਸਮਾਨ ਹੈ, ਅਤੇ ਤੱਤ ਤਬਦੀਲੀ ਜਾਣਕਾਰੀ ਦੀ ਇੱਕ ਯੂਨੀਫਾਈਡ ਪ੍ਰਤੀਨਿਧਤਾ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ IElementDelta ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।

ਚੌਲ. 10. ਹੈਂਡਲੀ ਨੋਟੀਫਿਕੇਸ਼ਨ ਵਿਧੀ ਦੇ ਆਮ ਇੰਟਰਫੇਸ ਅਤੇ ਬੁਨਿਆਦੀ ਲਾਗੂਕਰਨ

ਉੱਪਰ ਦੱਸੇ ਗਏ ਹੈਂਡਲੀ ਹਿੱਸੇ (ਚਿੱਤਰ 9 ਅਤੇ 10) ਨੂੰ ਲਗਭਗ ਕਿਸੇ ਵੀ ਹੈਂਡਲ-ਅਧਾਰਿਤ ਮਾਡਲਾਂ ਨੂੰ ਦਰਸਾਉਣ ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਬਣਾਉਣ ਲਈ ਭਾਸ਼ਾਈ ਮਾਡਲ, ਪ੍ਰੋਜੈਕਟ ਵਾਧੂ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ - ਖਾਸ ਤੌਰ 'ਤੇ, ਸਰੋਤ ਟੈਕਸਟ ਬਣਤਰ ਦੇ ਤੱਤਾਂ ਲਈ ਆਮ ਇੰਟਰਫੇਸ ਅਤੇ ਬੁਨਿਆਦੀ ਲਾਗੂਕਰਨ, ਅਖੌਤੀ ਸਰੋਤ ਤੱਤ (ਚਿੱਤਰ 8). ISourceFile ਇੰਟਰਫੇਸ ਇੱਕ ਸਰੋਤ ਫਾਈਲ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਅਤੇ ISourceConstruct ਸਰੋਤ ਫਾਈਲ ਦੇ ਅੰਦਰ ਇੱਕ ਤੱਤ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਐਬਸਟ੍ਰੈਕਟ ਕਲਾਸਾਂ SourceFile ਅਤੇ SourceConstruct ਸਰੋਤ ਫਾਈਲਾਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਤੱਤਾਂ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਵਿੱਚ ਸਹਾਇਤਾ ਕਰਨ ਲਈ ਸਧਾਰਣ ਵਿਧੀਆਂ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ, ਉਦਾਹਰਨ ਲਈ, ਟੈਕਸਟ ਬਫਰਾਂ ਨਾਲ ਕੰਮ ਕਰਨਾ, ਸਰੋਤ ਟੈਕਸਟ ਵਿੱਚ ਇੱਕ ਤੱਤ ਦੇ ਧੁਰੇ ਨਾਲ ਬੰਨ੍ਹਣਾ, ਇੱਕ ਕਾਰਜਸ਼ੀਲ ਕਾਪੀ ਬਫਰ ਦੀ ਮੌਜੂਦਾ ਸਮੱਗਰੀ ਨਾਲ ਮਾਡਲਾਂ ਦਾ ਮੇਲ ਕਰਨਾ। , ਆਦਿ ਇਹਨਾਂ ਵਿਧੀਆਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਆਮ ਤੌਰ 'ਤੇ ਕਾਫ਼ੀ ਚੁਣੌਤੀਪੂਰਨ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਹੈਂਡਲੀ ਉੱਚ-ਗੁਣਵੱਤਾ ਬੁਨਿਆਦੀ ਲਾਗੂਕਰਨ ਪ੍ਰਦਾਨ ਕਰਕੇ ਹੈਂਡਲ-ਅਧਾਰਿਤ ਭਾਸ਼ਾ ਮਾਡਲਾਂ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਦੇ ਯਤਨਾਂ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਘਟਾ ਸਕਦਾ ਹੈ।

ਉੱਪਰ ਸੂਚੀਬੱਧ ਕੋਰ ਵਿਧੀਆਂ ਤੋਂ ਇਲਾਵਾ, ਹੈਂਡਲੀ ਟੈਕਸਟ ਬਫਰਾਂ ਅਤੇ ਸਨੈਪਸ਼ਾਟ ਲਈ ਇੱਕ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਸਰੋਤ ਕੋਡ ਸੰਪਾਦਕਾਂ (Xtext ਸੰਪਾਦਕ ਦੇ ਨਾਲ ਆਊਟ-ਆਫ-ਦ-ਬਾਕਸ ਏਕੀਕਰਣ ਸਮੇਤ) ਦੇ ਨਾਲ ਏਕੀਕਰਣ ਲਈ ਸਮਰਥਨ, ਅਤੇ ਨਾਲ ਹੀ ਕੁਝ ਆਮ UI ਹਿੱਸੇ ਜੋ ਸਰੋਤ ਕੋਡ ਸੰਪਾਦਕਾਂ ਨਾਲ ਕੰਮ ਕਰੋ। ਹੈਂਡਲੀ ਮਾਡਲ ਜਿਵੇਂ ਕਿ ਰੂਪਰੇਖਾ ਫਰੇਮਵਰਕ। ਇਸਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਦਰਸਾਉਣ ਲਈ, ਪ੍ਰੋਜੈਕਟ ਹੈਂਡਲੀ ਵਿੱਚ ਜਾਵਾ ਮਾਡਲ ਨੂੰ ਲਾਗੂ ਕਰਨ ਸਮੇਤ ਕਈ ਉਦਾਹਰਣਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। (JDT ਵਿੱਚ ਜਾਵਾ ਮਾਡਲ ਦੇ ਪੂਰੇ ਲਾਗੂ ਕਰਨ ਦੀ ਤੁਲਨਾ ਵਿੱਚ, ਇਸ ਮਾਡਲ ਨੂੰ ਵਧੇਰੇ ਸਪੱਸ਼ਟਤਾ ਲਈ ਜਾਣਬੁੱਝ ਕੇ ਕੁਝ ਸਰਲ ਬਣਾਇਆ ਗਿਆ ਹੈ।)

ਜਿਵੇਂ ਕਿ ਪਹਿਲਾਂ ਨੋਟ ਕੀਤਾ ਗਿਆ ਹੈ, ਹੈਂਡਲੀ ਦੇ ਸ਼ੁਰੂਆਤੀ ਡਿਜ਼ਾਈਨ ਅਤੇ ਬਾਅਦ ਦੇ ਵਿਕਾਸ ਦੇ ਦੌਰਾਨ ਇੱਕ ਮੁੱਖ ਫੋਕਸ ਸਕੇਲੇਬਿਲਟੀ ਅਤੇ ਲਚਕਤਾ 'ਤੇ ਸੀ ਅਤੇ ਜਾਰੀ ਹੈ।

ਸਿਧਾਂਤ ਵਿੱਚ, ਹੈਂਡਲ-ਅਧਾਰਿਤ ਮਾਡਲ "ਡਿਜ਼ਾਇਨ ਦੁਆਰਾ" ਬਹੁਤ ਵਧੀਆ ਢੰਗ ਨਾਲ ਸਕੇਲ ਕਰਦੇ ਹਨ. ਉਦਾਹਰਨ ਲਈ, ਹੈਂਡਲ/ਬਾਡੀ ਮੁਹਾਵਰੇ ਤੁਹਾਨੂੰ ਇੱਕ ਮਾਡਲ ਦੁਆਰਾ ਖਪਤ ਕੀਤੀ ਗਈ ਮੈਮੋਰੀ ਦੀ ਮਾਤਰਾ ਨੂੰ ਸੀਮਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਪਰ ਸੂਖਮਤਾ ਵੀ ਹਨ. ਇਸ ਤਰ੍ਹਾਂ, ਜਦੋਂ ਮਾਪਯੋਗਤਾ ਲਈ ਹੈਂਡਲੀ ਦੀ ਜਾਂਚ ਕੀਤੀ ਗਈ, ਤਾਂ ਨੋਟੀਫਿਕੇਸ਼ਨ ਵਿਧੀ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਇੱਕ ਸਮੱਸਿਆ ਲੱਭੀ ਗਈ - ਜਦੋਂ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਤੱਤ ਬਦਲੇ ਗਏ, ਡੈਲਟਾ ਦੇ ਨਿਰਮਾਣ ਵਿੱਚ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੱਗ ਗਿਆ। ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਇਹੀ ਸਮੱਸਿਆ ਜੇਡੀਟੀ ਜਾਵਾ ਮਾਡਲ ਵਿੱਚ ਮੌਜੂਦ ਸੀ, ਜਿਸ ਤੋਂ ਇੱਕ ਵਾਰ ਅਨੁਸਾਰੀ ਕੋਡ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਇਆ ਗਿਆ ਸੀ. ਅਸੀਂ ਹੈਂਡਲੀ ਵਿੱਚ ਬੱਗ ਨੂੰ ਠੀਕ ਕੀਤਾ ਹੈ ਅਤੇ JDT ਲਈ ਇੱਕ ਸਮਾਨ ਪੈਚ ਤਿਆਰ ਕੀਤਾ ਹੈ, ਜੋ ਧੰਨਵਾਦੀ ਤੌਰ 'ਤੇ ਪ੍ਰਾਪਤ ਕੀਤਾ ਗਿਆ ਸੀ। ਇਹ ਸਿਰਫ਼ ਇੱਕ ਉਦਾਹਰਨ ਹੈ ਜਿੱਥੇ ਹੈਂਡਲੀ ਨੂੰ ਮੌਜੂਦਾ ਮਾਡਲ ਲਾਗੂਕਰਨ ਵਿੱਚ ਪੇਸ਼ ਕਰਨਾ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਅਜਿਹੇ ਬੱਗ ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਥਾਂ 'ਤੇ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਮੌਜੂਦਾ ਮਾਡਲ ਲਾਗੂਕਰਨਾਂ ਵਿੱਚ ਹੈਂਡਲੀ ਲਾਗੂ ਕਰਨ ਲਈ, ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਲਚਕਤਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਮੁੱਖ ਸਮੱਸਿਆ API ਮਾਡਲ ਵਿੱਚ ਪਿਛੜੇ ਅਨੁਕੂਲਤਾ ਨੂੰ ਬਣਾਈ ਰੱਖਣਾ ਹੈ। ਵਿਚ ਇਸ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕੀਤਾ ਗਿਆ ਸੀ ਹੱਥੀਂ 0.5 ਲਾਇਬ੍ਰੇਰੀ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ ਯੂਨੀਫਾਈਡ ਮੈਟਾ-ਪੱਧਰ API ਤੋਂ, ਡਿਵੈਲਪਰ ਦੁਆਰਾ ਪਰਿਭਾਸ਼ਿਤ ਅਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਿਯੰਤਰਿਤ ਮਾਡਲ-ਵਿਸ਼ੇਸ਼ API ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਵੱਖ ਕਰਕੇ। ਇਹ ਨਾ ਸਿਰਫ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਹੈਂਡਲੀ ਨੂੰ ਮੌਜੂਦਾ ਲਾਗੂਕਰਨਾਂ ਵਿੱਚ ਲਾਗੂ ਕਰਨਾ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ, ਸਗੋਂ API ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨ ਵੇਲੇ ਨਵੇਂ ਮਾਡਲ ਡਿਵੈਲਪਰ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਆਜ਼ਾਦੀ ਵੀ ਦਿੰਦਾ ਹੈ।

ਲਚਕਤਾ ਦੇ ਹੋਰ ਪਹਿਲੂ ਵੀ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਹੈਂਡਲੀ ਮਾਡਲ ਦੀ ਬਣਤਰ 'ਤੇ ਲਗਭਗ ਕੋਈ ਪਾਬੰਦੀਆਂ ਨਹੀਂ ਲਾਉਂਦਾ ਹੈ ਅਤੇ ਇਸਦੀ ਵਰਤੋਂ ਆਮ-ਉਦੇਸ਼ ਅਤੇ ਡੋਮੇਨ-ਵਿਸ਼ੇਸ਼ ਭਾਸ਼ਾਵਾਂ ਦੋਵਾਂ ਨੂੰ ਮਾਡਲ ਬਣਾਉਣ ਲਈ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਸਰੋਤ ਫਾਈਲ ਦੀ ਬਣਤਰ ਦਾ ਨਿਰਮਾਣ ਕਰਦੇ ਸਮੇਂ, ਹੈਂਡਲੀ AST ਨੁਮਾਇੰਦਗੀ ਦੇ ਕਿਸੇ ਖਾਸ ਰੂਪ ਦੀ ਤਜਵੀਜ਼ ਨਹੀਂ ਕਰਦਾ ਹੈ ਅਤੇ, ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ, ਖੁਦ AST ਦੀ ਮੌਜੂਦਗੀ ਦੀ ਵੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਇਸ ਤਰ੍ਹਾਂ ਲਗਭਗ ਕਿਸੇ ਵੀ ਪਾਰਸਿੰਗ ਵਿਧੀ ਨਾਲ ਅਨੁਕੂਲਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ। ਅੰਤ ਵਿੱਚ, ਹੈਂਡਲੀ ਈਲੈਪਸ ਵਰਕਸਪੇਸ ਦੇ ਨਾਲ ਪੂਰੀ ਏਕੀਕਰਣ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਪਰ ਇਸਦੇ ਨਾਲ ਏਕੀਕਰਣ ਦੇ ਕਾਰਨ ਫਾਈਲ ਸਿਸਟਮਾਂ ਨਾਲ ਸਿੱਧਾ ਕੰਮ ਵੀ ਕਰ ਸਕਦਾ ਹੈ। ਈਲੈਪਸ ਫਾਈਲ ਸਿਸਟਮ (EFS)।

ਮੌਜੂਦਾ ਵਰਜਨ ਹੱਥੀਂ 0.6 ਦਸੰਬਰ 2016 ਵਿੱਚ ਸਾਹਮਣੇ ਆਇਆ। ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਪ੍ਰੋਜੈਕਟ ਵਰਤਮਾਨ ਵਿੱਚ ਪ੍ਰਫੁੱਲਤ ਹੋਣ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਹੈ ਅਤੇ API ਨੂੰ ਅਜੇ ਅੰਤਮ ਰੂਪ ਵਿੱਚ ਨਿਸ਼ਚਿਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ, ਹੈਂਡਲੀ ਪਹਿਲਾਂ ਹੀ ਦੋ ਵੱਡੇ ਵਪਾਰਕ ਉਤਪਾਦਾਂ ਵਿੱਚ ਵਰਤੀ ਜਾਂਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨੇ "ਸ਼ੁਰੂਆਤੀ ਅਪਣਾਉਣ ਵਾਲੇ" ਵਜੋਂ ਕੰਮ ਕਰਨ ਦਾ ਜੋਖਮ ਲਿਆ ਸੀ, ਅਤੇ, ਮੈਨੂੰ ਕਹਿਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਸ ਨੂੰ ਅਜੇ ਤੱਕ ਪਛਤਾਵਾ ਨਾ ਕਰੋ.

ਜਿਵੇਂ ਕਿ ਉੱਪਰ ਨੋਟ ਕੀਤਾ ਗਿਆ ਹੈ, ਇਹਨਾਂ ਉਤਪਾਦਾਂ ਵਿੱਚੋਂ ਇੱਕ 1C: ਐਂਟਰਪ੍ਰਾਈਜ਼ ਡਿਵੈਲਪਮੈਂਟ ਟੂਲ ਹੈ, ਜਿੱਥੇ ਹੈਂਡਲੀ ਦੀ ਵਰਤੋਂ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਅਜਿਹੇ 1C ਦੇ ਉੱਚ-ਪੱਧਰੀ ਢਾਂਚੇ ਦੇ ਮਾਡਲਾਂ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ: ਐਂਟਰਪ੍ਰਾਈਜ਼ ਭਾਸ਼ਾਵਾਂ ਬਿਲਟ-ਇਨ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ ਅਤੇ ਪੁੱਛਗਿੱਛ ਭਾਸ਼ਾ ਵਜੋਂ। . ਇੱਕ ਹੋਰ ਉਤਪਾਦ ਆਮ ਲੋਕਾਂ ਲਈ ਘੱਟ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ. ਇਹ ਕੋਡਸਿਪ ਸਟੂਡੀਓ, ਐਪਲੀਕੇਸ਼ਨ-ਵਿਸ਼ੇਸ਼ ਹਦਾਇਤ-ਸੈੱਟ ਪ੍ਰੋਸੈਸਰ (ਏਐਸਆਈਪੀ) ਲਈ ਇੱਕ ਏਕੀਕ੍ਰਿਤ ਡਿਜ਼ਾਈਨ ਵਾਤਾਵਰਣ, ਜੋ ਕਿ ਚੈੱਕ ਕੰਪਨੀ ਕੋਡਾਸਿੱਪ ਦੇ ਅੰਦਰ ਅਤੇ ਇਸਦੇ ਗਾਹਕਾਂ ਦੁਆਰਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਸਮੇਤ AMD, ਔਸਤ, ਫਰਨੀਚਰ, ਸਿਗਮਾ ਡਿਜ਼ਾਈਨ. Codasip 2015 ਤੋਂ ਹੈਂਡਲੀ ਵਰਜਨ ਹੈਂਡਲੀ 0.2 ਤੋਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋਏ, ਉਤਪਾਦਨ ਵਿੱਚ ਹੈਂਡਲੀ ਦੀ ਵਰਤੋਂ ਕਰ ਰਿਹਾ ਹੈ। ਕੋਡਸਿਪ ਸਟੂਡੀਓ ਦੀ ਨਵੀਨਤਮ ਰੀਲੀਜ਼ ਜੂਨ 0.5 ਵਿੱਚ ਜਾਰੀ ਕੀਤੇ ਗਏ ਸੰਸਕਰਣ 2016 ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। ਕੋਡਾਸਿੱਪ ਵਿਖੇ IDE ਵਿਕਾਸ ਦੀ ਅਗਵਾਈ ਕਰਨ ਵਾਲੇ Ondřej Ilčík, ਪ੍ਰੋਜੈਕਟ ਦੇ ਸੰਪਰਕ ਵਿੱਚ ਹਨ, "ਤੀਜੀ ਧਿਰ ਅਪਣਾਉਣ ਵਾਲੇ" ਦੀ ਤਰਫੋਂ ਮਹੱਤਵਪੂਰਨ ਫੀਡਬੈਕ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹੋਏ। ਉਹ ਹੈਂਡਲੀ ਉਦਾਹਰਣਾਂ ਵਿੱਚੋਂ ਇੱਕ, ਜਾਵਾ ਮਾਡਲ ਲਈ ਇੱਕ UI ਲੇਅਰ (ਕੋਡ ਦੀਆਂ ~ 4000 ਲਾਈਨਾਂ) ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹੋਏ, ਪ੍ਰੋਜੈਕਟ ਦੇ ਵਿਕਾਸ ਵਿੱਚ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਹਿੱਸਾ ਲੈਣ ਲਈ ਕੁਝ ਖਾਲੀ ਸਮਾਂ ਲੱਭਣ ਦੇ ਯੋਗ ਸੀ। ਅਪਣਾਉਣ ਵਾਲਿਆਂ ਦੁਆਰਾ ਹੈਂਡਲੀ ਦੀ ਵਰਤੋਂ ਬਾਰੇ ਵਧੇਰੇ ਵਿਸਤ੍ਰਿਤ ਪਹਿਲੀ ਜਾਣਕਾਰੀ ਪੰਨੇ 'ਤੇ ਪਾਈ ਜਾ ਸਕਦੀ ਹੈ ਸਫਲਤਾ ਦੀਆਂ ਕਹਾਣੀਆਂ ਪ੍ਰੋਜੈਕਟ.

ਅਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹਾਂ ਕਿ API ਸਥਿਰਤਾ ਦੀ ਗਾਰੰਟੀ ਦੇ ਨਾਲ ਸੰਸਕਰਣ 1.0 ਦੇ ਜਾਰੀ ਹੋਣ ਤੋਂ ਬਾਅਦ ਅਤੇ ਪ੍ਰਫੁੱਲਤ ਸਥਿਤੀ ਨੂੰ ਛੱਡਣ ਵਾਲੇ ਪ੍ਰੋਜੈਕਟ, ਹੈਂਡਲੀ ਕੋਲ ਨਵੇਂ ਅਪਣਾਉਣ ਵਾਲੇ ਹੋਣਗੇ। ਇਸ ਦੌਰਾਨ, ਪ੍ਰੋਜੈਕਟ ਏਪੀਆਈ ਦੀ ਜਾਂਚ ਅਤੇ ਹੋਰ ਸੁਧਾਰ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦਾ ਹੈ, ਪ੍ਰਤੀ ਸਾਲ ਦੋ "ਮੁੱਖ" ਰੀਲੀਜ਼ ਜਾਰੀ ਕਰਦਾ ਹੈ - ਜੂਨ (ਸਮਕਾਲੀ ਈਲੈਪਸ ਰੀਲੀਜ਼ ਦੇ ਸਮਾਨ ਮਿਤੀ) ਅਤੇ ਦਸੰਬਰ ਵਿੱਚ, ਇੱਕ ਪੂਰਵ-ਅਨੁਮਾਨਿਤ ਅਨੁਸੂਚੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜਿਸ 'ਤੇ ਅਪਣਾਉਣ ਵਾਲੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹਨ। ਅਸੀਂ ਇਹ ਵੀ ਜੋੜ ਸਕਦੇ ਹਾਂ ਕਿ ਪ੍ਰੋਜੈਕਟ ਦੀ "ਬੱਗ ਦਰ" ਲਗਾਤਾਰ ਨੀਵੇਂ ਪੱਧਰ 'ਤੇ ਬਣੀ ਹੋਈ ਹੈ ਅਤੇ ਹੈਂਡਲੀ ਪਹਿਲੇ ਸੰਸਕਰਣਾਂ ਤੋਂ ਹੀ ਸ਼ੁਰੂਆਤੀ ਅਪਣਾਉਣ ਵਾਲਿਆਂ ਦੇ ਉਤਪਾਦਾਂ ਵਿੱਚ ਭਰੋਸੇਯੋਗਤਾ ਨਾਲ ਕੰਮ ਕਰ ਰਹੀ ਹੈ। Eclipse Handly ਦੀ ਹੋਰ ਪੜਚੋਲ ਕਰਨ ਲਈ, ਤੁਸੀਂ ਵਰਤ ਸਕਦੇ ਹੋ ਟਿਊਟੋਰਿਅਲ ਸ਼ੁਰੂ ਕਰਨਾ и Archਾਂਚੇ ਬਾਰੇ ਜਾਣਕਾਰੀ.

ਸਰੋਤ: www.habr.com